Re: [boost] Submission: typelist

From: Peter Dimov (pdimov_at_[hidden])
Date: 2001-11-26 07:29:11

From: "Andrei Alexandrescu" <andrewalex_at_[hidden]>
> I just uploaded typelist.zip for review. It contains three header files
and
> a cpp test file.
[...]
> 1. Header null_typelist.hpp
>
> class null_typelist;
>
> * Defines a class that is used by convention as a typelist terminator. I
> didn't use boost::tuple's null_type because in the long haul, if typelists
> will be accepted, it would be more logical that tuples depend on
typelists,
> and not vice versa.

Agreed. We already had this discussion on the list before but I'd like to
revisit it:

class nil;

> 2. Header type_manip.hpp
>
> template <int v> struct int2type;
>
> * Maps integral constants to values. As I'm sure you know, this little
> template has a lot of uses. Exposes value which evaluates to the passed-in
> constant.
>
> template <typename T> struct type2type;
>
> * Maps each type to a unique, insipid type. Exposes T as original_type.

::type?

> template <bool flag, typename T, typename U> struct select;
>
> * The well-known "compile-time if". It is present in mpl as well as in
> detail/select_type.hpp. By this I am making a suggestion to give
> "compile-time if" full boost citizenship - not as a member of a library or
a
> detail.

Indeed, the compile-time if is already present in a number of boost
libraries. My only concern is that I'd never be able to remember that a
compile-time if is defined in a header called type_manip.hpp.

> template <class T, class U> struct type_list;
>
> * Guess what :o).

What? ;-)

Have you considered using std::pair as the 'dot pair' type? It doesn't
really matter which template is used as long as it has two type parameters -
it doesn't even need a definition. std::pair is handy since it automatically
maps a value list (a tuple) to a typelist.

Unless you need to pass _instances_ of typelists around, of course. Is there
such a need?

> namespace tl
> {
>     template <class TList> struct no_duplicates;

unique? remove_duplicates?

> }
>
> * There is some controversy around the TYPELIST_nn macros. The best
solution
> uses an extralinguistic mechanism, which is sort of "cheating" but sounds
> pretty good. I believe that the one true solution is to change the
language.
> I am eager to hear suggestions and I would love it if the ensuing
discussion
> would lead to a good solution.

Why did you reject the make_typelist<...>::type approach?

A general comment about the library: there is significant overlap between
the proposal, the existing tuple library and the upcoming mpl. I'd like to
see this addressed - somehow.

--
Peter Dimov
Multi Media Ltd.