Boost logo

Boost :

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.

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