Boost logo

Boost :

Subject: Re: [boost] [outcome] expected, etc. why are these assignable
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2017-06-03 08:25:35

Le 03/06/2017 à 00:09, Peter Dimov via Boost a écrit :
> Niall Douglas wrote:
>> My argument in favour of an emoty state is because the implementation
>> will implement an empty state internally anyway, so either you expose
>> that publicly, or you don't. It's no difference for the implementation.
> The same argument has been used in variant's case and the initial
> proposal did include a bona fide empty state. It was however swept
> under the carpet because never-empty, or even the illusion of
> never-empty, as in the case of C++17's variant, was found preferable.
> It's true that the implementation will have an empty state internally
> as an implementation detail, but it need not be user-visible.
> The argument for never having an empty state, in variant's case, is
> that having an empty state makes people who don't use it pay for it in
> more complex code that has to check for empty because visit, for
> example, has to handle all alternatives. It's better, there, to make
> the default never empty. People who want an empty state can always put
> an empty alternative in the list.
The same argument justify IMHO the narrow contracts for the observers.


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