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

From: Douglas Gregor (gregod_at_[hidden])
Date: 2002-08-09 11:51:26

On Friday 09 August 2002 04:03 am, Itay Maman wrote:
> ii) assignment should be optimized for the case where the two varaints are
> holding incomplete values:
>     variant<incomplete<A>, B, C> v1;
>     varriant<incomplete<X>, Y, Z> v2;
>
>     v1 = v2;  // incomplete<A> = incomplete<X> can be carried in safely
>
> The second item (ii) has been suggested before (by Doug), but we decided to
> put it somewhere on the bottom of the list, since (at that time) it was
> nothing more than an optimization. Now, it offers attractive safety
> implications.

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!

Here's what I propose: let's build a comprehensive list of cases where we can 
provide the strong guarantee. The cases should be based on type traits so 
that they can be explored via a metaprogram. With this information, we can 
estimate how much of the "type space" can be covered while keeping the strong 
guarantee for swap/assign.

        Doug