If Hana is the slow, "full fat" metaprogramming library,
Hana is not a "slow, full fat" metaprogramming library. Quite far from that. It's just that for pure type-level metaprogramming (which by the way is quite rarely needed nowadays with deduced return types), we can't possibly be as fast as Brigand, Metal or such type-level only solutions that is highly optimized for that precise use case.
is there space remaining for exactly one fast, "lightweight" metaprogramming library?
The problem is that the term metaprogramming is overloaded to mean several things. It can either mean pure type-level metaprogramming (MPL world), or algorithms on tuples (Fusion world). It HAPPENS that the latter is powerful enough to perform the former; this is what Hana allows and then you only need one metaprogramming library. However, that is heavier compile-time wise and does not scale as well as a library that was crafter with type computations only from the start. And if that was your question, I don't think you can do what Hana does (i.e. handle Fusion + MPL) while being significantly faster. You might be able to be some small constant factor faster, but that's it. By the way, these libraries for pure type-level metaprogramming have the same problem, it's just that their constant factors are smaller than Hana's. Take any of these libraries and try to process a type list with 200K elements while doing something non-trivial. The fundamental problem is that we need language-level support for metaprogramming if we want to go completely crazy with it, and some of us are working exactly on this right now for C++next (or maybe the one after). Louis -- View this message in context: http://boost.2283326.n4.nabble.com/About-all-these-metaprogramming-libraries... Sent from the Boost - Dev mailing list archive at Nabble.com.