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

Subject: Re: [boost] [variant] Please vote for behavior
From: Joel de Guzman (djowel_at_[hidden])
Date: 2013-01-29 18:07:04

On 1/30/13 1:25 AM, Jeffrey Lee Hellrung, Jr. wrote:
> On Tue, Jan 29, 2013 at 7:12 AM, Paul Smith <pl.smith.mail_at_[hidden]> wrote:
>
>> On Mon, Jan 28, 2013 at 8:27 PM, Joel de Guzman <djowel_at_[hidden]> wrote:
>>> On 1/29/13 1:40 AM, Paul Smith wrote:
>>>>>
>>>>> I am also
>>>>>> not convinced that drawing from objects with "singular" values is
>> wrong,
>>>>>> regardless if it's a pointer or not. I think it is you who's missing
>>>>>> the point because Iterators are likewise*not*  pointers.
>>>
>>>
>>>> Okay, so replace "recursive_wrappers are not pointers" with
>>>> "recursive_wrappers are not iterators". How does it make it any
>>>> different? A singular value still doesn't fit in.
>>>
>>>
>>> The point is that iterators can have singular values. If iterators
>>> can have them, why can't any other object (have them)?
>>
>> Why should any other object have them? Iterators are a generalization
>> of pointers and that's where they inherit their singular state from.
>> This has absolutely nothing to do with move-semantics, and that's
>> exactly why I say that such inferences, just like the NaN example, are
>> dangerously superficial. A moved-from iterator isn't singular just
>> like a default-constructed recursive_wrapper isn't. Different concepts
>> - different issues. The point I'm trying to make is that conceptually
>> recursive_wrappers don't have a value of their own. They have exactly
>> the same set of states as their underlying type. If this type has a
>> singular value, then and only then does a recursive wrapper around
>> this type has a singular value.
>>
>>> IMO, ultimately,
>>> it's a matter of design. You may not agree with a recursive_wrapper
>>> being in a "singular" state after move, but that's just your preference.
>>
>> Okay, I'm not sure what exactly we are disagreeing about anymore.
>>
>> Do we agree that the move semantics we have in C++ are non-destructive
>> (I'm not asking whether you like it or not. At this point it's a fact
>> - not a preference)? If you agree with that, then you should
>> appreciate that it's like that for a reason, whether or not you agree
>> with that reason.
>>
>> A moved-from object should remain in a valid state. You're suggesting
>> meeting this requirement by introducing a new (and yes, breaking)
>> state, let's bluntly call it the "invalid" state, and you don't see
>> what I'm talking about when I say that this is just missing the point?
>> Then there's really nothing more I can say...
>>
>>> IMO, it's necessary for proxy-like objects that own and hold their
>>> subjects by pointer. It's not quite elegant, sure, but C++ is never
>>> elegant in many respects for the sake of high performance. I'd trade
>>> this quirk for the sake of efficiency any day.
>>
>> That's a rant about how move semantics in C++ turned out (completely
>> intentionally) to be. This discussion isn't about that, it's about how
>> recursive_wrapper should behave under these semantics.
>>
>
> 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.

No, Jeff, that is wrong. We are not violating the semantics to variant.
It's not about variant. It's about recursive_wrapper. I think people are
confused with this. The variant's never-empty guarantee still holds.
A variant holding a singular-valued recursive_wrapper is similar to
a variant holding a singular valued iterator. The variant is not empty.

Regards,
-- 
Joel de Guzman
http://www.boostpro.com
http://boost-spirit.com