Boost logo

Boost :

Subject: Re: [boost] [variant] Please vote for behavior
From: Joel de Guzman (djowel_at_[hidden])
Date: 2013-01-28 13:35:40

On 1/29/13 2:18 AM, Larry Evans wrote:
> 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 <> wrote:
>>>> On 1/26/13 7:58 AM, Dave Abrahams wrote:
>>>>>> I completely agree with the notion that a moved-from object simply
>>>>>> should
>>>>>>> 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
>>> state.
>>>> 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.
> [snip]
> 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:
> template<T>
> operator()(recursive_wrapper<T>const& rw)
> and the user would have to test rw::_p?

No. It's still just operator(T const&). You can't use a "singular
valued" recursive_wrapper in any other operation apart from assignment,
destruction or move.


Joel de Guzman

Boost list run by bdawes at, gregod at, cpdaniel at, john at