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

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

-regards,
Larry