Boost logo

Boost :

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


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.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk