Why does it need to be identical? Can't you just use decltype(r.error())? As long as you know that at minimum it supports the error_code interface this should be sufficient for most purposes.
It doesn't work unfortunately because you need to convert from error_code interface compliant type A to error_code interface compliant type B, and what does "convert" mean exactly? Remember, the TRY implementation can have no knowledge of what the return type of the enclosing function is.
There was talk (not sure if it was an official proposal or just a suggestion) of something like decltype(return) for getting the type returned from the current function.
Even without that, couldn't TRY accept the return type as a parameter?
It doesn't especially help you in practice. What Outcome currently does is return magic type sugar from TRY which is implicitly constructible by any basic_monad instance, this works around needing to know what the return type is for the calling function in the TRY implementation.
Besides, if the intent is to convey the payload up the call chain, then it can be left to the responsibility of the method itself to forward that appropriately -- ie. if you call something that can return an error_code_info<EI1> then you are required to do one of the following:
1. Deal with the error locally, not calling TRY. 2. Call TRY to pass on the error unmodified, thereby requiring that you also return an error_code_info<EI1>. 3. Pass on the error, but returning error_code_info<EI2> where EI2 is constructible from EI1 (forwarding the original payload plus some additional context). This might be a special case of #1.
(By "returning" here I don't mean directly, I mean wrapped in a result<> or outcome<>.)
Of course you could do all that. What I'm saying is that for 95% of programmers, when facing the choice of whether to use different E types in exchange for typing a ton load more boilerplate all day long every day in everything they write, they will - I guarantee you - choose just to make the error type the same throughout the entire program. It makes things *simple*. All that said, given that my non-variant Outcome plan has much more compile time budget than before, I certainly can make constructors all templated and SFINAEd in a way presented Outcome could not without blowing out compile times. One therefore could enable implicit construction from some arbitrary other error type if the user has implemented implicit conversion between error types. I think that would enable what you are proposing? Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/