Re: [boost] Outcome v2

Subject: Re: [boost] Outcome v2
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2017-07-11 23:45:29

On 12/07/2017 02:18, Niall Douglas wrote:
> On 11/07/2017 12:53, Peter Dimov wrote:
>> I would make outcome<> reuse 100% of result<>'s implementation, by
>> stealing another page from your playbook:
>>
>> class extended_error_code
>> {
>>     std::error_code e_;
>>     std::exception_ptr x_;
>> };
>>
>> template<class T> using outcome = result<T, extended_error_code>;
> 
> That may well happen yet. What held me back was that the universality of
> EC = error_code is very important in order to use TRY effectively.
> That's what led to the split design you see today, so you're basically
> exchanging some purity in the design for ease of programming. TRY is
> such a boon for not typing boilerplate.

Perhaps:

struct extended_error_code : public std::error_code
{
     std::exception_ptr ex;
};

template<class T> using outcome = result<T, extended_error_code>;

This allows generic code to treat EC exactly as a std::error_code (both 
for method calls and to slice off the exception if they wish).

Having said that, this would basically render it impossible to have 
value + exception *without* an error_code.  You could mitigate that by 
defining a default "there is an exception" error_code (which you might 
be doing anyway), though it feels a little weird.  (Then again, it's 
probably worse to leave the std::error_code default-constructed.)

> A majority of peer review feedback didn't see the need for variant
> storage. Eliminating it very significantly reduces the complexity of the
> implementation, it's a big gain. I was able to SFINAE all the
> constructors because of the compile time budget released by eliminating
> the variant storage.

If you're going to maintain strict no-value-plus-error semantics then 
union/variant storage makes sense, as otherwise you're wasting memory. 
I'm not sure why this would increase complexity.