Re: [boost] [variant2] Formal review

Subject: Re: [boost] [variant2] Formal review
From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2019-04-15 06:59:46

On Sun, Apr 14, 2019 at 4:48 PM Gavin Lambert via Boost <
boost_at_[hidden]> wrote:
>
> On 15/04/2019 08:58, Emil Dotchevski 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.
>
> As I've said elsewhere, I don't see the difference between "is this
> empty" and "did this unexpectedly change type", except that the former
> is easier to detect (and hence better).

Let's say an error occurs, and a member variant's state now violates the
invariants of the enclosing type. If there is a special empty state -- or
if there isn't -- under the basic guarantee you'd catch the exception and
do work to restore the invariants. There is no difference in the recovery
steps, and once they are complete, there is nothing to detect, the object
is as valid as any other.

The benefits of the never-empty guarantee are elsewhere, not during error
handling, in that the presence of the empty state requires the program to
deal with it.