Re: [boost] [variant] Please vote for behavior (Was: Basic rvalue and C++11 features seupport)

Subject: Re: [boost] [variant] Please vote for behavior (Was: Basic rvalue and C++11 features seupport)
From: Larry Evans (cppljevans_at_[hidden])
Date: 2013-01-24 14:56:03

On 01/21/13 17:51, Hartmut Kaiser wrote:
>> On 1/22/13 3:57 AM, Antony Polukhin wrote:
>>> I've got some nice idea from discussion: nullable variant. If many
>>> people use or want to use a variant with a type, that represents empty
>>> state, we can create a separate nullable variant class. I think that
>>> nullable variant can be implemented more efficient that the current
>>> variant. For example we can simplify copy/move constructors and
>>> assignment operators, guarantee fast noexcept default construction,
>>> simplify metaprogamming and reduce compilation times. Maybe someone
>>> want to implement it?
>>
>> I like it! If you implement it, I'll be your first user :-) I don't really
>> care much about this "never empty" guarantee and I think it's not really
>> worth the trouble.
> 
> I'd prefer to have a nullable variant as well. If not that, then I would
> like to support II: Set operand.p_ to NULL, add BOOST_ASSERT in get
> operations.
> 

OR have get<T> return recursive_wrapper<T> and then the user
would have to check whether it's nulled.  This avoids the
need for BOOST_ASSERT; however it does violate the contract:

This "never-empty" property insulates the user from the possibility of
undefined variant content and the significant additional
complexity-of-use attendant with such a possibility.

mentioned here:

http://www.boost.org/doc/libs/1_52_0/doc/html/variant/design.html#variant.design.never-empty

however, setting operator.p_ to NULL does the same but makes
it harder for the user to detect since the user would have to
use a try/catch to test it, IIUC.

-regards,
Larry