Re: [boost] Re: Variant size bug?

From: Joel de Guzman (joel_at_[hidden])
Date: 2003-11-03 19:01:15

David Abrahams <dave_at_[hidden]> wrote:

> 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.

Ok. I like the type_sequence<X>::type spelling. That's better.

>> 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 ;-)]

Indeed! I guess I still had the hangover from yesterday when I wrote
that reply :-) 

>> 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.

Please disregard that. That's a non-issue (a hangover issue, in fact :-)
So, we have 2 solutions:

    1) provide a type_sequence<X>::type 
    2) provide an mpl::begin<X> and mpl::end<X>

No. 1 is the easiest to implement. No. 2 would require some knowledge of
mpl's tag mechanism to do easily, otherwise would require partial specialization.
No. 2 will make X a conforming mpl type sequence.

Thoughts? 

-- 
Joel de Guzman
http://www.boost-consulting.com
http://spirit.sf.net