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.
#define MOZ_TRY(expr) \
do { \
- auto mozTryTempResult_ = (expr); \
+ auto mozTryTempResult_ = ::mozilla::ToResult(expr); \
if (mozTryTempResult_.isErr()) { \
return ::mozilla::Err(mozTryTempResult_.unwrapErr()); \
} \
} while (0)
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.
--
Nicolas B. Pierron
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
