Boost logo

Boost :

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.

Boost list run by bdawes at, gregod at, cpdaniel at, john at