Re: [boost] [variant] Please vote for behavior

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 <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
>>>>>> 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.

Regards,
-- 
Joel de Guzman
http://www.boostpro.com
http://boost-spirit.com