On Mon, Jan 28, 2013 at 2:02 AM, Joel de Guzman <djowel@gmail.com> wrote:
I think we are OK!
Come to think of it, the situation is a lot like a "singular" iterator:
"Iterators can also have singular values that are not associated with any sequence. [snip] Results of most expressions are undefined for singular values; the only exceptions are destroying an iterator that holds a singular value, the assignment of a non-singular value to an iterator that holds a singular value, and, for iterators that satisfy the DefaultConstructible requirements, using a value-initialized iterator as the source of a copy or move operation."
Indeed, for a singular valued iterator, i, you can assign to i and destruct i, place i in a container, etc. You just cannot dereference i, access its underlying value through ->, compare i with another iterator, etc.
The same is true with a nulled recursive_wrapper.
Being honest about this is just a matter of documentation. I do not see any problem at all with having a "singular" recursive_wrapper value.
Then you're still thinking in terms of destructive move. The reason why you don't see a problem with a "singular valued" recursive_wrapper (that's what we call it now? :-) is that you don't think anyone will try to use it. And, c'mon, it's not just a matter of documentation - we're not trying to weasel our way out of this. Adding a new and entirely different state just for the sake of move construction is a polite way of ignoring the possiblity that moved-from objects will be used. It might win you a case in court, but it's completely missing the point. Besides, drawing from iterators to recursive_wrappers is dangerous. They're completely different things. A recursive_wrapper's value *is* its underlying object's value - it's not a pointer. Talking about "singular values" under this concept doesn't make sense. If you want a recursive_wrapper that has an empty state, that's fine. But it's a different concept that deserves a different type. -- Paul Smith