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
> 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.
>> 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  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 , 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk