On 8/06/2017 03:02, Gottlob Frege wrote:
On Wed, Jun 7, 2017 at 6:43 AM, Niall Douglas wrote:
On 07/06/2017 00:02, Gavin Lambert wrote:
On 6/06/2017 21:23, Niall Douglas wrote:
Also, if you want the TRY operation to work (and you really, really do, it is an enormous boilerplate saver), then your error type needs to be identical throughout your program. Templating it breaks that.
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? Or perhaps rather than returning directly it could output to a parameter that the enclosing code declares to be the same as the return type (especially since you say you're using this two-phase in many cases anyway). 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<>.)