Re: [boost] [outcome] To variant, or not to variant?

Subject: Re: [boost] [outcome] To variant, or not to variant?
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2017-06-01 17:20:38

Le 01/06/2017 à 09:26, Andrzej Krzemienski via Boost a écrit :
> 2017-05-31 19:06 GMT+02:00 Vicente J. Botet Escriba via Boost <
> boost_at_[hidden]>:
>
>> Le 31/05/2017 à 15:15, Niall Douglas via Boost a écrit :
>>
>>> On 31/05/2017 11:31, Vicente J. Botet Escriba via Boost wrote:
>>>
>>>
>>> It's something I've often pondered for Outcome as well because it could,
>>> if done right, let me eliminate error_code_extended.
>>>
>>> The main thing which has stopped me is the potential confusion. For
>>> example, right now we have result<T> which can be
>>> empty|T|error_code_extended. If I instead made:
>>>
>>> template<class T, class Payload = void> class result;
>>>
>>> Now result could be (empty|T|std::error_code U Payload). But if this
>>> review to date with 600+ emails has been complicated, imagine a review
>>> of such a payload-carrying result object?
>>>
>>> std::error_code + payload is obvious. But, what does an empty state +
>>> payload mean? I have no idea.
>>>
>>> Indeed, what does a T state + payload mean? I guess that is Lawrence's
>>> status_value<> use case, but the problem is that the Payload type is
>>> fixed between variant states of empty|T|std::error_code and that surely
>>> is not particularly useful, you'd want different payload types with each
>>> of T or std::error_code. That's why I didn't implement it.
>>>
>> You lost me.
>>
>>> Still, I'd be interested in what people think. The other option is
>>> empty|T|status_value<std::error_code, Payload>, that would make more
>>> sense, but at the potential cost of bloating the stack significantly
>>> which could surprise end users in a way error_code_extended can not.
>>>
>>> You lost me definitely.
>> status_value is a product type because we need some additional information
>> even when the operation succeeds. The status is there to convey this
>> information, but conveys also the information explaining why the result is
>> not there.
>>
>> status_value<S,T> could be seen as pair<variant<Sucsess, Failure>,
>> optional<T>>
>>
>> There is an invariant Success <=> optional present and Failure <=>
>> optional not present.
>>
>> You could as well see it as variant<pair<Sucsess, T>, Failure> or
>> expected<pair<Sucsess, T>, Failure>
>>
> What the OP means is that status_value can bee seen as a "superset" of
> expected. It can cover all cases `expected` covers plus more. Of course,
> this "more" is not necessarily better or harmless.
>

I will not say is a super set as expected<pair<Success, T>, Failure> 
could be used instead of status_value.
I will say just it provides a different interface and can be more 
adapted to people that use to use status with positive and negative meaning.

Vicente