On Sun, Apr 14, 2019 at 12:53 PM Rainer Deyke via Boost < boost@lists.boost.org> 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@lists.boost.org> 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.