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-30 18:42:17

On 1/31/13 12:16 AM, Dave Abrahams wrote:
>
> on Mon Jan 28 2013, Joel de Guzman <djowel-AT-gmail.com> wrote:
>
>> On 1/28/13 12:18 AM, Dave Abrahams wrote:
>>>
>>> on Sat Jan 26 2013, Joel de Guzman <djowel-AT-gmail.com> 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 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.
>
> Yes, it's like a singular iterator, but it's a lot more like a null
> pointer.  A singular iterator is like (and may in fact be) an
> uninitialized pointer, over which the program does not and cannot exert
> any control.  A null pointer, on the other hand, has been initialized to
> a known state, but one in which some operations (e.g. *p, ++p, --p,
> p[0], ...) are not allowed.  Or you could think of it as being like the
> a zero-valued primitive numeric type, which you can't use as a divisor.
>
>> 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
>> value.
>
> Does it break backward-compatibility, by changing the guarantees users
> have about the possible values of certain variant types?  If so, the
> documentation should make that clear as well.

Thank you Dave for your insights. That is sensible and reasonable. In the
end, it's all about the variant's invariant alright :-P. I can see now how
it may break backward compatibility. Yet, that would be an extremely rare
situation and IMO, the practicality of a highly efficient move far
outweighs this backward-compatibility issue.

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