Re: [boost] An extension to boost::variant

Subject: Re: [boost] An extension to boost::variant
From: Chris Hamilton (chamilton_at_[hidden])
Date: 2009-02-09 16:20:05

>> Caveat: There would be a small violation to the "Never Empty Guarantee"
>> if a reference was the first templated type and the variant was default
>> constructed; in this case, it would be default constructible (as
>> internally it would be stored using a pointer), but the pointer would
>> have a null value.  Trying to use this value would cause an error,
>> obviously.
> 
> So you are consciously asking for something which you will know will pose a
> threat to the existing promises laid by the present variant. Interesting!

If you'd read what I just said, this would only be in the case where the
reference type was used as the first template parameter.  It is already
stated in the documentation that the resulting boost::variant is only
default constructible if the first type is; the "never empty guarantee"
would similarly only stand if the first type is not a reference (and, in
fact there are other ways around even this).  So, it doesn't change the
behaviour of any existing valid code using boost::variant, and would at
most add another byline to the 'concepts' documentation.  No need to get
too excited over this...

>> The problem remains: the variant<...> class doesn't know how to handle
>> 'operator=(
>> foo& f )'.
> 
> It is not a problem I think rather it is feature in the light the
> caveat(just one of many such worms) you mentioned above.
> 
> So by now, you have learned that you can gladly use variant like
> boost::variant<foo*,boost::reference_wrapper<foo> > v.
> 
> Now to the question of "The problem is that the user has to be aware that
> they are passing a
> reference by explicitly wrapping it.":
> 
> To achieve this, you can easily cook up some wrapper which will do the type
> forwarding magic by using type traits gimicks like is_reference on the user
> type before passing it to variant.

Once again, in earlier mails I stated that I want to use boost::variant
for *runtime polymorphism*.  That is, the boost::variant<...> would be
an argument type in a non-templated function.  This function is meant to
be exposed directly to the user in an API.  Thus, for each of these
functions, I'd have to wrap it in a templated wrapper which does the
type_traits magic.  Why not address it in a single place, ie: in the
boost::variants class?

I'm a little tired of running in circles here.  Anybody else care to
weigh in on the issue?

Cheers,

Chris