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]>
> 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
> > > various functions in the program must check "is the object empty" and
> > > define behavior for that case. The benefit of the never-empty guarantee
> > > 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
> > 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk