On 01/29/13 17:07, Joel de Guzman wrote:
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@gmail.com> wrote:
On Mon, Jan 28, 2013 at 8:27 PM, Joel de Guzman <djowel@gmail.com> 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.
The page: http://www.boost.org/doc/libs/1_52_0/doc/html/variant/design.html#variant.de... says: variant may be viewed precisely as a union of exactly its bounded types but having a singular-valued recursive_wrapper violates this view, because there's no way you can dereference a singular-valued recursive_wrapper to get at one of the bounded types. -regards Larry