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

Subject: Re: [boost] [outcome] High level summary of review feedback accepted so far
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2017-06-03 10:56:43

Le 27/05/2017 à 18:28, Niall Douglas via Boost a écrit :
>>> I would assume an expected<T, E1, .., En> could only return a
>>> std::variant<E1, ..., En> from its .error(). I can't think what else
>>> it could do.
>> As the foremost authority on the nonexistent expected<T, E...>, I can
>> tell you what it does:
>>
>>     // F shall be in E...
>>     template<class F> bool has_error() const;
>>     template<class F> F error() const;
>>
>>     // if sizeof...(E) == 1
>>     bool has_error() const;
>>     E1 error() const;
>>
>> It returns the equivalent of variant<E...> not from error(), but from
>>
>>     unexpected<E...> unexpected() const;
>>
>> which allows you to
>>
>>     expected<T, E1, E2, E3> function()
>>     {
>>         expected<U, E1, E2> e1 = function1();
>>         if( !e1 ) return e1.unexpected();
>>
>>         expected<V, E3> e2 = function2();
>>         if( !e2 ) return e2.unexpected();
>>
>>         return e1.value() + e2.value();
>>     }
> That's a second approach.
>
> A third approach could be implementing .index() and std::get<>() for
> expected.
>
I believe, expected should implement the SumType operations when we 
agree on what they are. This doesn't mean that we need .index and 
std::get, these are specific to variant  ;-)

I believe that the variant interface is not the one we need to adopt for 
sum types, in the same way the product type interface shouldn't be the 
one of tuples. We have other product types (those to which structured 
binding applies) that I don't see how they can have the tuple interface. 
Maybe I'm wrong and we are able to do it, but I don't think we should.
I suspect that we will have the same issue with future language sum types.

Vicente