Boost logo

Boost :

Subject: Re: [boost] [outcome] How to drop the formal empty state
From: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2017-05-24 20:53:28


2017-05-24 21:43 GMT+02:00 Niall Douglas via Boost <boost_at_[hidden]>:

> There has been a fair bit of review feedback that people don't like the
> formal empty state in outcome<T> and result<T>. I still think this
> opinion daft, just because it's there doesn't mean you have to use it,
> but here are some options:
>
> 1. Like Expected, we could require the E types to provide a nothrow move
> constructor. This would allow us to guarantee no empty state, not ever.
> Default constructing an outcome<T> or result<T> would set a default
> constructed T state, just like Expected.
>
> The only remaining difference now between result<T> and expected<T>
> would be the wide vs narrow observer functions. outcome<T> still can
> also carry a std::exception_ptr.
>
> 2. We could do the above, but default constructor constructs to some
> constexpr undefined state that is not state T nor E.
>
> 3. We could only provide a guarantee of no empty state if the E types
> provide nothrow move construction, but if they do not we fall back to an
> empty state arising if throws occur during assignment.
>
> 4. The option for an empty state becomes a template parameter defaulted
> to false i.e. disabled. This can be combined with any of the above.
>
> Thoughts?
>

Let me just clarify the nomenclature here. I understand that the only thing
you *need* to have is the *moved-form* state. There is no strong need to
provide a default constructor. Sure if you have a moved-from state, you
might as well use it in default constructor, but it is not the only option.
You could allow the moved-from state only as the result of a move.

Regards,
&rzej;


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk