Re: [boost] [outcome] expected, etc. why are these assignable

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.

Vicente