
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