Re: [boost] [variant] Please vote for behavior

Subject: Re: [boost] [variant] Please vote for behavior
From: Dave Abrahams (dave_at_[hidden])
Date: 2013-02-06 16:08:00

on Fri Feb 01 2013, Edward Diener <eldiener-AT-tropicsoft.com> wrote:

> On 1/30/2013 8:33 PM, Dave Abrahams wrote:
>>
>> on Tue Jan 29 2013, Paul Smith <pl.smith.mail-AT-gmail.com> wrote:
>>
>>> On Tue, Jan 29, 2013 at 7:25 PM, Jeffrey Lee Hellrung, Jr.
>>> <jeffrey.hellrung_at_[hidden]> wrote:
>
>>
>>>> This discussion might be facilitated if Joel et al (sorry Joel, I don't
>>>> mean to pick on you, I just mean the group arguing for introducing this
>>>> "singular" post-move state) simply said "yes, we understand we're making a
>>>> breaking change (by possibly introducing an additional state to variant
>>>> that violates the never-empty guarantee), but we still think it's the most
>>>> practical approach to introduce efficient move semantics to variant". I can
>>>> jive with that but I think Paul's concerned that you (again, as a
>>>> representative of the platform you're taking) don't appreciate that this is
>>>> a breaking change to variant.
>>>
>>> I think this is about a little more than that, even though to be
>>> honest, I'm not entirely sure what's the dispute is about too.
>>> I think it's closer to what Edward Diener said:
>>>
>>>    The main issue seems to be simply this: are guarantees ( invariants )
>>>    for an object of a class meant to cover moved from objects of that
>>>    class?
>>
>> I don't think that question should really even be on the table.  If
>> "invariant" and "guarantee" are to have any useful meaning, the answer
>> must be "yes."
>
> I agree with you but that means to me that for a class to be movable
> an invariant for that class can never be that the class cannot be
> empty.

Not so.  Throwing move constructors are allowed.

> It seems to me that the Variant class does have an invariant which
> says that the class can never be empty. So my conclusion is that a
> Variant can not be movable.

Probably not, unless you change (weaken) the invariant... though I
haven't really thought through the implications of a possible throwing
move constructor.

-- 
Dave Abrahams