Boost logo

Boost :

Subject: Re: [boost] [variant2] Formal review
From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2019-04-14 20:58:01

On Sun, Apr 14, 2019 at 12:53 PM Rainer Deyke via Boost <
boost_at_[hidden]> wrote:
> On 14.04.19 20:16, Emil Dotchevski via Boost wrote:
> > On Sun, Apr 14, 2019 at 10:19 AM Rainer Deyke via Boost <
> > boost_at_[hidden]> wrote:
> >>
> >> On 13.04.19 19:26, Bjorn Reese via Boost wrote:
> >>> * std::variant which enters an invalid (valuless_by_exception)
> >>> While that may be appropriate for some use cases, there are
> >>> where it is not. For instance, the variant may be used for a
> >>> machine where the alternative types are function object types
to be
> >>> invoked when events arrive. Having a valueless state is the
> >>> choice for this use case.
> >>
> >> Wait. I don't understand how never-empty is an advantage in this
> >>
> >> The invariants of the state machine can still be broken.
> >
> > It is not the job of variant to maintain the invariants of the state
> > machine, that is the job of the state machine.
> 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.

This is orthogonal to maintaining higher-level invariants: if an error
occurs and the result is that a member variant<> object goes in a valid
state which violates the invariants of the containing type, the containing
type has to do work to provide the basic guarantee, with or without the
never-empty guarantee.

Boost list run by bdawes at, gregod at, cpdaniel at, john at