Vicente J. Botet Escriba wrote:
Your rational to use a prefix mp_ let me perplex. Does it mean that namespaces have not reached its goal?
Namespaces work well most of the time, but metaprogramming is a bit of a special case, because many of the identifiers we'd like to use in a metaprogramming library are either keywords (if, int, false) or already exist in namespace std (list, fill). The former forces us to add the suffix _ at times, the latter has been known to create problems via argument-dependent lookup. It's of course possible to use a namespace, meta:: as in Eric's library, or perhaps mp::, but I don't think that it buys us much.
IMO, both mp_append_impl and mp_append are useful. Do you think that we don't need any more the functionality of the mp_append_impl in c++1/c++14? If you considered it still useful, maybe you can follow the standard naming convention mp_append and mp_append_t.
The point I am making by not using the standard _t convention is that in C++11 aliases should be our primary primitive. The origin of the _t convention is that the ordinary non-_t traits were there first because there was no other way, and then the _t convenience aliases were added as an afterthought. This is a historical artifact. A C++11 design that does not have its origins in C++03 could and should choose the non-_t name for the alias.
The use of mp_list<> in mp_append_impl when there are 0 arguments is weird. Just wondering if adding a template
class R argument would make everything clearer.
The "idiomatic" way of making mp_append use a specific R is mp_append