Re: [boost] [variant2] Formal review

Subject: Re: [boost] [variant2] Formal review
From: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2019-04-15 10:55:41

pon., 15 kwi 2019 o 09:06 Emil Dotchevski via Boost <boost_at_[hidden]>
napisał(a):

> On Sun, Apr 14, 2019 at 11:57 PM Rainer Deyke via Boost <
> boost_at_[hidden]> 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_at_[hidden]> 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. It is enough if I can see all the control
flows and see that neither of them produces the undesired state.

In the case of variant and its vaueless_by_exception state the undesired
state only occurs when someone is not doing their exception handling right.
So, technically the unwanted state could be constructed. But putting a
defensive if-statement for concealing symptoms of bugs in some other other
function would be the wrong way to go.

Regards,
&rzej;