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

Subject: Re: [boost] [outcome] expected, etc. why are these assignable
From: Peter Dimov (lists_at_[hidden])
Date: 2017-06-02 22:09:57

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.