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

Subject: Re: [boost] [outcome] To variant, or not to variant?
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2017-05-31 23:15:04

On 31/05/2017 22:31, Vicente J. Botet Escriba wrote:
> Does none_t mean success or failure?

Either; that's up to the method in question.  It also wasn't really the 
focus of the question so you can pretend it doesn't exist if that makes 
you happier.

> For what I see it means failure as it is not the result of value().

That was a consequence of trying to keep it returning by reference as 
some people seem to prefer.  If it returned by value then it could 
return an optional<T>, which might be better.

> In addition it default construct to none_t.

That was intentional.

>> private:
>>     optional<T> m_value;
>>     error_code m_error;
>>     exception_ptr m_exception;
>> };
>>
> I guess you want a variant here. You don't want to store all of them, 
> isn't it?

No, that was the entire point: to store all of them, and not as a variant.

> I could understand
> 
>      varaint<optional<T>, variant<error_code, exception_ptr>>

Nested variants are utterly pointless.  In an ideal world variant would 
automatically collapse nested sub-variants to reduce storage, although 
that does unfortunately complicate return-by-reference semantics.

> This corresponds to the status_value [1] model where you store the 
> reason why you don't have a value or why you have it and an 
> optional<value>. As described by L. Crowl in [2], there are use cases 
> for status_value, expected and exceptions.
> 
>      pair<optional<T>, variant<error_code, exception_ptr>>
> 
> Where we have a value of error_code to mean success.

That's closer to my second suggestion, yes, although I think using 
pair<> is a disservice.  I also don't think error_code and exception_ptr 
are necessarily exclusive.