Re: [boost] [outcome] Second high level summary of review feedback accepted so far

Subject: Re: [boost] [outcome] Second high level summary of review feedback accepted so far
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2017-06-07 23:10:16

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<>.)