Subject: Re: [boost] [variant] Please vote for behavior
From: Paul Smith (pl.smith.mail_at_[hidden])
Date: 2013-01-28 12:40:38
On Mon, Jan 28, 2013 at 6:11 PM, Joel de Guzman <djowel_at_[hidden]> wrote:
> On 1/28/13 10:10 PM, Paul Smith wrote:
>> On Mon, Jan 28, 2013 at 2:02 AM, Joel de Guzman <djowel_at_[hidden]> 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
>>> 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
>> 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.
> Oh man, here we go again.
Sorry, I didn't mean to be irritating. I'm honestly not trying to
spite. If this discussion gets heated, I quit.
> No I am not convinced. Sorry. The standard
> only mentions assign and destroy as necessary
Really, where? [moveconstructible] has much stricter requirements than that.
This issue has been discussed more than once before, and nothing I say
here is my own opinion, so please don't take it out on me.
For example, see N3264 (CH-18 and US-85: Clarifying the state of
moved-from objects (Revision 1)):
> and Dave confirms that,
I don't want to read into what Dave said too much, because he's here
and he can clarify it. But I believe what he said is that specific
algorithms, in their own localized context, practically only require
destructibility and assignability. And even then, it's not something
the standard actually guarantees in general, though, and the
requirements are still much stricter, perhaps superfluously so. That's
frustrating, no doubt about it, and it's a good selling point for
having destructive move semantics - not for breaking the rules.
> as did people like Stanley Lippman (C++ Primer 5th Edition).
I didn't read the book, but as you see, there's a lot of controversy
and misconception around this subject, so I'll take everything with a
grain of salt. If you have a quote, that would be helpful.
> 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.
-- Paul Smith
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk