[boost] Re: Variant size bug?

From: David Abrahams (dave_at_[hidden])
Date: 2003-11-03 15:57:22

"Joel de Guzman" <joel_at_[hidden]> writes:

> Persson Jonas <jonas.persson_at_[hidden]> wrote:
>
>>> Well, technically it's not a bug: variant<> *is*
>>> variant<boost::empty>.
>>> 
>>> I agree this may be unexpected, and so should probably be noted more
>>> explicitly in the docs.
>>> 
>>> Also, we _can_ argue whether this unexpectedness constitutes a bug in
>>> variant's design. (It's certainly not an *implementation* bug though.)
>> 
>> Well, I would argue that it is a (design) bug. It breaks the
>> typelist <-> variant symmetry, and causes some of the mpl stuff to
>> give the wrong result.
>> Is there any reason why the user would want the interface to work
>> this way?
>> 
>> I use mpl to unroll the types in the variant, so I must have a
>> termination condition. As it stands now I cannot use mpl::size or
>> mpl::empty for that. How do I check at compile time if the variant
>> contains any types or not?
>
> Since modern boost libraries with a typelist interface such as tuples
> and variant use MPL anyway, it would be nice to expose a typelist
> typedef so that people can get the typelist and process it using MPL.
> Examples:
>
> template <typename T0, typename T1... , typename TN>
> class variant 
> {
> public:
>
>     typedef implementation-defined typelist;
>
>     /*...*/
> };
>
> template <typename T0, typename T1... , typename TN>
> class tuple
> {
> public:
>
>     typedef implementation-defined typelist;
>
>     /*...*/
> };

Ahem.  Tuples should already be functioning mpl type sequences, IMO.
It would be nice if variant would be the same.  If not possible in
either case for some reason, there should be a *non-intrusive*
type_sequence<X>::type metafunction invocation which gets the type
sequence.

"typelist" is the wrong name; it implies exposure of an implementation
detail.

   
> Another alternative is to ask MPL to open up its namespace to allow
> the specialization of  mpl::begin<s> and  mpl::end<s>, 

They're already specializable (why wouldn't they be?).  More
conveniently and portably, you can nest a ::tag type and then
fully-specialize mpl::begin_traits/end_traits.

[But then, you should know this from the book preview, Joel ;-)]

> so we can add our own typelist-savvy classes. It wouldn't be
> possible, due to potential name clashes to put the begin<s>, end<s>
> in the class' namespace. For example, Fusion already has a begin(t)
> and end(t) functions and it's not legal to have both a class/struct
> and a function in the same namespace.

I don't see why that's a problem.  mpl::begin<T> and fusion::begin(t)
can be different.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com