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:40:44

On 1/30/13 5:00 AM, Paul Smith wrote:
> On Tue, Jan 29, 2013 at 7:25 PM, Jeffrey Lee Hellrung, Jr.

>> 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 ?
>
>    All of the choices which you have specified, which popularly boils down
>    to II or III, involves this question. The choice of II answers No to the
>    question above while the choice of III answers Yes to the question above.
>
> As absurd as it may sound right now, I think Joel's and mine opinions
> are much closer than it seems. I like performance too, believe it or
> not. And it's not just about performance, under non-destructive move
> semantics there's an entire class of objects which is neither copyable
> nor movable, and it becomes harder to give no-throw guarantees. I
> definitely *do* want to be able to move recursive_wrapper by nulling
> it's pointer. I think what we disagree on is how to get there :-)

Ok, let's just agree to disagree then and leave it at that. You say
that we can't do that now because we are violating the standard if
we do. I say that that understanding is wrong. Dave's note is pretty
clear to me:

 >> (The) ability to both assign and destroy? Is that all that it needs?

 > That's all the standard library will use.

I think I've said enough on this subject matter.

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