Subject: Re: [boost] [variant] Please vote for behavior
From: Larry Evans (cppljevans_at_[hidden])
Date: 2013-01-28 13:18:13
On 01/27/13 18:02, Joel de Guzman wrote:
> On 1/28/13 12:18 AM, Dave Abrahams wrote:
>> on Sat Jan 26 2013, Joel de Guzman <djowel-AT-gmail.com> wrote:
>>> On 1/26/13 7:58 AM, Dave Abrahams wrote:
>>>>> I completely agree with the notion that a moved-from object simply
>>>>>> not be used in any manner.
>>>> Well, that's just wrong, for the non-destructive move model used by the
>>>> standard. The standard library relies on the ability to both assign
>>>> and destroy moved-from elements. If you want destructive move,
>>>> that's a
>>>> whole research project. We on the committee who created rvalue
>>>> references couldn't figure out how to make it work.
>>> (The) ability to both assign and destroy? Is that all that it needs?
>> That's all the standard library will use. However, you still have to be
>> honest about the variant's invariant: it must include the moved-from
>>> Then we should be OK. A nulled recursive_wrapper can both be assigned
>>> and destroyed. It just can't do other things apart from that, such
>>> as get the underlying T& and call its member functions.
>> I am not familiar enough with the details of recursive_wrapper and how
>> much of it is exposed to users to know whether any of this matters. You
>> have to choose: either the addition of this moved-from state must not
>> invalidate any previous guarantees upon which users may rely, OR you
>> have to tell them that you're breaking backward-compatibility and
>> document that the moved-from state is an "anti-precondition" for all the
>> "other things apart from that."
>> Or you could invent a whole new concept of "invariant" that is allowed to
>> be violated... but I really discourage that! :-)
> 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.
What would a visitor do in this case? Currently, it requires
a non-null recursive_wrapper, IIUC.
If a nulled recursive_wrapper were allowed, would the visitors
then need to supply:
and the user would have to test rw::_p?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk