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
> "typelist" is the wrong name; it implies exposure of an implementation
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.
-- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk