On Tue, May 09, 2017 at 12:50:26PM +0000, Nicolas B. Pierron wrote:
On 05/07/2017 07:34 PM, Kris Maglione wrote:
static inline Result<Ok, nsresult>
WrapNSResult(PRStatus aRv)
{
if (aRv != PR_SUCCESS) {
return Err(NS_ERROR_FAILURE);
}
return Ok();
}
static inline Result<Ok, nsresult>
WrapNSResult(nsresult aRv)
{
if (NS_FAILED(aRv)) {
return Err(aRv);
}
return Ok();
}
#define NS_TRY(expr) MOZ_TRY(WrapNSResult(expr))
This sounds like we could have a template function named ToResult(),
which is used by the MOZ_TRY macro to coerce a given type into the
equivalent mozilla::Result<> type. This ToResult function could be
specialized to forward the Result<…> arguments by default.
Yeah, I wasn't especially happy with the NS_TRY name either, and
just handling the case for MOZ_TRY had occurred to me. I mainly
went with a separate macro to try to avoid confusion, but I'd
definitely be happy to reuse MOZ_TRY.
The main concern that I have with that approach at that point is
avoiding unnecessary copies or moves. I'm not sure how well the
compiler would legally be able to optimize that for complex
Result types.
Another concern would be the representation of the Result<Ok,
nsresult> (or Result<nssuccess, nsfailure> ?), which should definitely
be represented as an nsresult, as this enum is capable of representing
success with NS_OK, and also various other forms of success values.
There is already a way to specialize the PackingStrategy of the Result
class to consume less space, and it can be used to specialize the way
we encode such Result<Ok, nsresult> class, to avoid the overhead of
duplicating the success flag.
This sounds like a good idea. We'd have to assert that NS_OK was
never used as the failure value, but it seems doable.
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform