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.
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
can be expressed more easily. The MPL Sequence concept is compatible with several
other Boost libraries (most importantly Fusion),
so another reason is interoperability.
Despite their syntax, pointer to member object types can be seen as dereferencing functionals.
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.
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.
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.
It was found preferable that the following condition holds:
mpl::size< parameter_types<T> >::value == function_arity<T>::value
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.