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
