Re: [boost] [variant2] Need rationale for never-empty guarantee

Subject: Re: [boost] [variant2] Need rationale for never-empty guarantee
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2019-03-01 10:14:15

> The guarantee provided by variant's assignment is not a strong exception
> safety guarantee: it is possible that my variant has value A, I want to
> assign value B, and (due to an exception) I end up with value C. If this
> happens, the only thing I can reasonably do is to either abandon whatever I
> was doing or reset the variant to the state that I need. So the guarantee
> that it is not left empty does not seem to be of much use. But the cost to
> be paid is noticeable.

I would disagree with this assessment of the strong never empty
guarantee provided by variant2.

I have only seen a certain amount of std::variant being used in the
wild, written by average C++ developers. In every such case, however, I
have never seen any accounting for the possibility of the std::variant
being valueless, despite that the codebase does throw exceptions, and
that the std::variant is not in temporary storage duration.

I find that to be a code smell. In the code I have written myself where
I used std::variant, I know it will be later modified by programmers who
may not account for valueless. I therefore have always wrapped my use of
std::variant with valueless handling code, even if it isn't needed right
now, in order account for the future possibility that someone might add
a type which can throw during move or copy. It also reminds later
programmers about valueless, so it is self documenting.

This, in my opinion, is exactly the situation which so many people
objected to WG21 regarding the possibility of valueless at all in
std::variant. It introduces a corner case which few will consider, and
it is certainly virtually untestable, so anyone sensible is going to
wrap every std::variant with a wrapper to handle valueless.

I find that situation daft. And it was completely avoidable.

For me, a HUGE tick in favour of variant2 is that it has the design
which std::variant should have had from the beginning, at little build
time nor runtime cost over std::variant.

I will therefore be strongly recommending the use of variant2 instead of
std::variant wherever possible. Until WG21 clean up that mess, which I
hope variant2 will help persuade them to do.

Niall