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

Subject: Re: [boost] [variant] Please vote for behavior
From: Jeffrey Lee Hellrung, Jr. (jeffrey.hellrung_at_[hidden])
Date: 2013-02-01 21:32:06

On Fri, Feb 1, 2013 at 5:51 PM, Edward Diener <eldiener_at_[hidden]>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.
> 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.
>

Not true. First of all, the primary present issue is implementing move
semantics for a variant with recursive_wrapper. Non-recursive variants
aren't really a problem.

Second, specifically for recursive variants, if one of the underlying types
is default constructible (trivially, ideally!), then, again no issues (in
theory; such a solution isn't presently implemented). So we basically have
this very "narrow" case (recursive variant with no detectable
default-constructible types) which is the issue, and even then, we have a
solution (it's just, by all accounts, suboptimal, since it has to use new
sometimes).

- Jeff