Re: [boost] variant invariant

From: Emil Dotchevski (emil_at_[hidden])
Date: 2008-08-04 16:56:10

On Mon, Aug 4, 2008 at 12:48 PM, Steven Watanabe <watanabesj_at_[hidden]> wrote:
> AMDG
>
> Emil Dotchevski wrote:
>>>>
>>>> Also, I am not necessarily advocating strong exception guarantee. I
>>>> would be fine if the semantics of operator= were such that it may
>>>> leave the object in a particular unusual state. The problem is that as
>>>> it is now, it may leave the object in a seemingly OK state.
>>>>
>>
>> Yes, I was aware of this workaround and of the one Mathias mentioned.
>>
>> However, variant<foo,bar,blank> and variant<wrapper<foo>,wrapper<bar>>
>> aren't the same as variant<foo,bar>. I'm questioning the rationale of
>> the current variant::operator= semantics, not necessarily looking for
>> a way to work around them.
>
> It doesn't seem unreasonable to require boost::blank to be listed,
> in order to allow a variant to be left in a "particular unusual state"

It depends on the viewpoint. If you have operator= which may change
the type of the stored value, it's quite reasonable to specify that if
you list boost::blank as a valid type, it will be preferred over the
other valid types.

This still doesn't mean that it is desirable for operator= to be
allowed to change the type of the stored object.

If you list boost::blank as a valid variant, then there's nothing
unusual about this state. The difference in meaning is subtle but
nevertheless important: it's similar to a pointer that may legally be
null, requiring the user to deal with this possibility, vs. a pointer
which can never be null, allowing the user to assert when it is.

Emil Dotchevski
Reverge Studios, Inc.
http://www.revergestudios.com/reblog/index.php?n=ReCode