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: Joel de Guzman (djowel_at_[hidden])
Date: 2013-01-28 12:38:01

On 1/29/13 12:47 AM, Larry Evans wrote:
> On 01/21/13 18:25, Joel de Guzman wrote:
>> On 1/22/13 8:13 AM, Jeffrey Lee Hellrung, Jr. wrote:
>>> On Mon, Jan 21, 2013 at 3:54 PM, Joel de Guzman <djowel_at_[hidden]> wrote:
>>>
>>>> On 1/22/13 7:49 AM, Jeffrey Lee Hellrung, Jr. wrote:
>>>>
>>>>> On Mon, Jan 21, 2013 at 3:33 PM, Joel de Guzman <djowel_at_[hidden]>
>>>>> 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.
>>>>>>
>>>>>>
>>>>> How is this different from variant< blank, ... > ?
>>>>>
>>>>
>>>> Less work behind the scenes.
>>>
>>>
>>> You mean fewer LOC / simpler implementation (believable) or faster
>>> compiled
>>> code (I'd be skeptical)?
>>
>> Agreed.
>>
>>>> Lighter TMP load.
>>>
>>>
>>> Agreed, but I'm not sure how much the "never empty guarantee" accounts
>>> for
>>> the present TMP load.
>>
>> Agreed.
>>
>>> better noexcept
>>>> guarantees. Etc.
>>>>
>>>
>>> I don't see this. I would think constructing blank has the same noexcept
>>> guarantees as assigning a pointer to null, and can equally well be
>>> propagated out to the variant interface. You might have a specific
>>> case in
>>> mind, though?
>>
>> No. After thinking about it for a while, you are right.
>>
>>> Do you presently use variant< blank, ... >? If not, is it because of the
>>> above reasons?
>>
>> I *always* use variant< blank, ... > (or something similar). And that is
>> precisely why I don't care much about the never-empty guarantee.
>>
>> Regards,
>
> I'm a bit confused about what nullable variant means.  I can see 2
> possible interpretations:
>
>    1) allow recursive_wrapper<T>::_p == 0.
>       This only occurs when moving from a variant
>       containing a recursive_wrapper.
>    2) ensure a moved from variant is put into the same
>       state as a default constructed variant.

Closer to 2. A nullable_variant is simply a variant with an implied
"blank" type as the first in the type list. It's equivalent to

   variant<blank, T...>

I can imagine that the implementation of this will be cleaner and
simpler than the current implementation with lots of code that
deals with the never-empty guarantee.

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