Boost logo

Boost :

Subject: Re: [boost] [variant2] Need rationale for never-empty guarantee
From: mike.dev_at_[hidden]
Date: 2019-03-03 08:20:15


> -----Original Message-----
> From: Boost <boost-bounces_at_[hidden]> On Behalf Of Niall Douglas via Boost
>
> > variant2 also only provides *basic* exception safety guarantee: you can be
> > assigning a variant containing type B to a variant containing type A and
> > end up with variant containing type C. Here's an example:
> > https://wandbox.org/permlink/AObFiUKgeXIEiXQa
>
> I just don't get why variant2 would set a state of C when it had state
> A, and setting state B failed. It should have spotted the lack of common
> noexcept move, employed double buffers, and alternated between them such
> that state A is untouched should setting state B fail.
>
> If it's going to do weirdness like setting state C out of the blue, then
> better dispose entirely any double buffered implementation as not adding
> value.

I have to agree with Niall here (at least partially).

When I have a variant that holds value "a" of type A and I assign a value
"b" of type B to it, I expect to end up either with a, b
or an error state if such a state is modeled by the variant type *).
Falling back to a completely unrelated type C seems very surprising to me.
Even more confusing would probably be the case if A or B happen to be the
"fallback" type and I'd end up with a default constructed A or B instead
of either a or b.

*) I prefer an error state that is part of the variant type
   like valueless_by_exception. I'm also fine with a "fallback state"
   that is explicitly blessed like monostate. But it should not be the
   first type from the typelist that happens to be noexcept default
   constructible.

In summary: Just as stated by Niall, I'd prefer either getting the strong
exception guarantee or an explicitly modeled error state.

On a related but different topic: I think it would be useful if one was able
to statically assert if a variant2<A,B,C,D> type uses double buffering
or not.

Best
Mike


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