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 <
> 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
> >>> 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk