Re: [boost] [variant2] Formal review

15 Apr 2019

      On Mon, Apr 15, 2019 at 3:56 AM Andrzej Krzemienski via Boost <
boost@lists.boost.org> wrote:
...
pon., 15 kwi 2019 o 09:06 Emil Dotchevski via Boost 
napisał(a):
...
On Sun, Apr 14, 2019 at 11:57 PM Rainer Deyke via Boost <
boost@lists.boost.org> wrote:
...
On 14.04.19 22:58, Emil Dotchevski via Boost wrote:
...
On Sun, Apr 14, 2019 at 12:53 PM Rainer Deyke via Boost <
boost@lists.boost.org> wrote:
...
Yes, but the question was about the benefits of the never-empty
guarantee.  If the never-empty guarantee doesn't help with
maintaining
...
...
...
...
...
higher level invariants, then what benefit does it bring?
If the design allows for one more state, then that state must be
handled:
various functions in the program must check "is the object empty"
and
define behavior for that case. The benefit of the never-empty
guarantee
is
that no checks are needed because the object may not be empty.
No.  A function is not required to check its invariants and
preconditions.  If a function is defined as taking a non-empty
variant,
then it is up to the caller to make sure the variant is not empty
before
passing it to the function.
The point is, there will be checks, in various functions (e.g. in "the
caller"), except if we know the state is impossible, A.K.A. the
never-empty
guarantee.
...
If the function is a member of the same
object as the variant and the object requires that the variant is
non-empty as an invariant, then it is up to the other member functions
of the object to maintain that invariant.  In both cases the function
can just assume that the variant is non-empty.
For someone to be able to assume, someone has to do the checking, or
else
we have the never-empty guarantee.
This is a popular misunderstanding of preconditions and invariants. In
order to guarantee that some state of the object never occurs, I do not
have to check this anywhere.
But we do, std::variant does in fact have checks.

The point you're making is that the checks are not needed if we specify
that calling e.g. visit after assignment failure is UB, but that violates
the basic guarantee. Once we introduce the empty state, logically, either
we have checks or we lose the basic guarantee. But maybe you also think
that the basic guarantee is useless.