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.