Subject: Re: [boost] "Simple C++11 metaprogramming"
From: Peter Dimov (lists_at_[hidden])
Date: 2015-05-31 08:00:20
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
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
> The use of mp_list<> in mp_append_impl when there are 0 arguments is
> weird. Just wondering if adding a template <class ...> class R argument
> would make everything clearer.
The "idiomatic" way of making mp_append use a specific R is mp_append<R<>,
...>, which is not that much harder to use than the hypothetical
As a general rule, I prefer to keep functions homogeneous if possible.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk