Re: [boost] [variant2] Formal review

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)
state.
> >>>       While that may be appropriate for some use cases, there are
others
> >>>       where it is not. For instance, the variant may be used for a
state
> >>>       machine where the alternative types are function object types
to be
> >>>       invoked when events arrive. Having a valueless state is the
wrong
> >>>       choice for this use case.
> >>
> >> Wait.  I don't understand how never-empty is an advantage in this
example.
> >>
> >>    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.