Re: [boost] Re: Empty boost::variant semantics (was Re: Re:Mini-reviewrequest: aligned_storage.hpp)

From: David Abrahams (dave_at_[hidden])
Date: 2002-08-09 11:52:26

From: "Douglas Gregor" <gregod_at_[hidden]>

> Yes, I think we should revisit this, and I think we should consider
requiring
> the strong guarantee for swap & assignment, because as it is formulated
I'm
> not sure we can claim that it even meets the basic guarantee. Quote Dave:
>
>   " *  The basic guarantee: that the invariants of the component are
> preserved, and no resources are leaked."
>
> Can we really say that the invariants of the component are preserved? I
don't
> think so. We need to define some invariant that says what value is "in"
the
> variant at a given time, so we have two options:
>   1) either a value of a type in the set of types {T1, T2, ..., TN} or no
> value (variant is empty)
>   2) a value of a type in the set of types {T1, T2, ..., TN}
>
> We decided long ago that #1 is bad, because it makes variants harder to
use.
> But if we choose #2, then the current assign/swap semantics don't meet
the
> basic guarantee!

I don't understand why that must be the case. Are we still working with
assign_as<T>, swap_as<T> et al?
If so, it seems to me that these can just dispatch to the operation defined
for T, and assuming T's assignment meets the basic guarantee, all is well.

I don't expect to be able to repair exception-broken types (i.e. those
whose operations don't even meet the basic guarantee).

-----------------------------------------------------------
           David Abrahams * Boost Consulting
dave_at_[hidden] * http://www.boost-consulting.com