Rationale

Error handling rationale

The library does not define the required members of class templates in case of an error. This technique causes the compiler to stop displaying diagnostics in client code, at the point where the error actually is, instead of tracing template instantiations into the implementation of the library.

The library's components have limited error conditions, so problematic input can be spotted easily.

Why MPL Sequences?

MPL provides algorithms on Sequences, so transformations (such as turning by-value parameter types into const references for optimized forwarding or computing a signature to specialize boost::function after applying boost::bind) can be expressed more easily. The MPL Sequence concept is compatible with several other Boost libraries (most importantly Fusion), so another reason is interoperability.

Pointer to member object types

Despite their syntax, pointer to member object types can be seen as dereferencing functionals.

The ClassTransform template parameter

This-pointer, this-reference or just the object (or maybe even a smart pointer to the object) plus adjustments of cv-qualification - all these cases have their place, somewhere and there is no single best answer.

Special treatment of the class type within the sequence can significantly complicate client code. A custom ClassTransform argument allows the client to adjust the class type before the sequence is formed and then treat all parameters uniformly.

Why tag types?

Let's consider the alternatives.

The first one is just using more templates so every property has to be asked for explicitly. This approach results in more complicated client code if more than one propery has to be checked and in a exponentially larger library interface.

The second alternative is having the client pass in bit patterns via non-type template parameters. The logic has to be performed by the client and there are much more error conditions. Further, class templates with non-type template parameters do not work within MPL lambda expressions and can cause problems with older compilers.

Is it safe to have the synthesis templates take a callable builtin type or an MPL sequence as the first template argument?

Yes, but it isn't immediately obvious as the set of possible MPL sequences isn't inherently disjoint from the set of callable builtin types.

However, any attempt to make a builtin type work as an MPL sequence is a bad idea, because builtin types are accessible before the headers that make the type a sequence have been included, which can easily violate the ODR.

Why does the hidden `this` parameter count for the function arity of member functions?

It was found preferable that the following condition holds:

mpl::size< parameter_types<T> >::value == function_arity<T>::value

Why ignore top-level cv-qualifiers on pointers?

A cv-qualified pointer is still a pointer. It usually doesn't matter and even if it does, it's a job for Boost.TypeTraits.