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