Proposed metaprogramming type system

From: Peter Dimov (pdimov_at_[hidden])
Date: 2001-12-17 09:23:19

Purpose:

* provide a common MPL/Loki subset enabling future compatible evolution of
the libraries and their eventual acceptance into Boost.

* failing that, provide a common threat for MPL and Loki authors enabling
their cooperation. ;-)

Synopsis:

namespace mpl
{

struct missing; // missing argument in a variadic function

struct nil;
template<class, class> struct pair;

struct _1; // bind/ET placeholders
struct _2;
// ...

template<class T, T v> struct ct_value
{
    static const T value = v;
};

template<class T> struct ct_type
{
    typedef T type;
};

}

Type system:

The metaprogramming library operates on types only. Compile-time values are
wrapped in ct_value<Type, Value>.

(Rationale: practice shows that attempting to cover compile-time values as
well results in excessive duplication. ct_value<> is chosen to avoid having
separate bool_t, int_t, uint_t, size_t_t and so on.)

The primary data structure is a binary tree represented by pair<Left,
Right>. The most common special case is the list, defined recursively as:

* nil is a list, called the empty list.
* pair<F, R> is a list iff R is a list.

No type defined by the library, except ct_type<T>, is guaranteed to have an
accessible constructor (or be a complete type) unless stated otherwise.
Values that correspond to a type T can be obtained using the expression
ct_type<T>().

(Rationale: it is not yet clear how should the compile-time subset of C++
interact with the traditional part of the language. On a conforming
compiler, the library can be written (and used) in such a way as to not
assume any specific properties of the types, leaving the door open for
future evolution.)

ct_type<T>, although compatible with the compile-time function identity<T>,
is a separate type with a distinct purpose.

Naming convention:

Identifiers that collide with keywords or other C++ reserved identifiers are
prefixed with ct_. Example: ct_if<class Cond, class Then, class Else>::type.

The result of a compile-time function is obtained using function<A1, ...,
An>::type.

For convenience, some compile-time functions return compile-time values, as
well, obtained via function<A1, ..., An>::value.

Compile-time functions that take a non-type argument are suffixed with 'v'.
Example: ct_ifv<bool Cond, class Then, class Else>::type.

"Quoted" compile-time functions are suffixed with 'q' and are invoked using
the function::template apply<A1, ..., An>::type syntax (on a conforming
compiler.) Example: ct_ifq.

(Rationale: not perfect, but better than no convention.)

STL iterator idiom compatibility:

A list provides forward iterators. For the list (a1 a2 ... aN), the iterator
to its k-th element is (ak ak+1 .. aN). The beyond-the-end iterator is nil.

Example: the compile-time function find<L, E>::type returns the sublist
starting with the first occurence of E in L, up to the end of L. The return
'value' can be used as an iterator, or it can be used as a condition in
ct_if (ct_if considers nil and ct_value<bool, false> to be false, everything
else to be true.)

--
Peter Dimov
Multi Media Ltd.