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

Subject: Re: [boost] [variant] Please vote for behavior
From: Edward Diener (eldiener_at_[hidden])
Date: 2013-02-02 07:54:42

On 2/1/2013 9:32 PM, Jeffrey Lee Hellrung, Jr. wrote:
> 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).

If you are going to be moving data from an object, but you must still 
recreate some of that data after the move so as not to leave the object 
empty, this does not seem to me to be a very successful move. Perhaps we 
are in the land of "we say it is a 'move' but actually we are doing 
'copying' of some of the data and moving the rest". Fair enough, but the 
gist of 'moving' as I understand it is that the moved from object is 
empty after the move even though the object still must be in a usable 
state. I admit that I do not see in the current standard where a moved 
from object cannot still contain a copy of some of the data which has 
been moved from it, but I still would have thought that the concept of a 
movable object is that it is empty of its data after the move.