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, ...) 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
> 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.
-- Joel de Guzman http://www.boostpro.com http://boost-spirit.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk