Bruno Dutra
My concern about hana is that it seems to have evolved way beyond what MPL does and so wouldn't serve as a "drop-in" improvement. I don't know about Eric's effort but I believe he's said he can't bring to the level of a boost library and no one has expressed any interest.
That's exactly the point I was trying to make. Hana is awesome, but it doesn't fit as a replacement for MPL, simply because it was meant for a different purpose. I see no reason why they shouldn't live side by side, each filling its specific niche.
I'm a bit late in the game because this thread has gone under my radar; please excuse that, I was busy working on Hana :-). Hana was designed as a replacement for both the MPL and Fusion. Technically, everything you can express with the MPL can be expressed with Hana; I'm working on a mathematical proof for it. The question really is whether it is _convenient_ to do so, and my current opinion is yes. However, metaprogramming with Hana requires you to stop thinking in a MPL way, i.e. with traditional metafunctions. If you keep your old MPL habits, you will end up having to decltype function call expressions all the time, which I agree is cumbersome. If you embrace this new way of metaprogramming, you will only have to use decltype at some precise boundaries; when you actually _need_ a type at the end of the whole computation. My assumption in designing Hana was that while all of our current type-level computations are implemented at the type-level, this is just a side effect of using the MPL and we actually need the types only at some thin boundaries. I suspect (1) the lack of guidelines for doing type-level metaprogramming in Hana (2) the lack of a serious case study (e.g. implementing Phoenix with Hana) could be why people don't see Hana as being fit for a MPL replacement; they don't see how we can achieve type-level metaprogramming easily, which is legitimate given (1) and (2). I clarified the tutorial[1] to improve the situation of (1), but there is still room for improvement. As for (2), I guess I am the one who should take the lead; if someone has a suggestion for a good guinea pig, please let me know. Otherwise, I started implementing the core of Accumulators with Hana; we'll see how that goes. FWIW, I am personally not in favor of having two metaprogramming libraries living side by side. This causes code duplication and interoperation issues, and it also increases the learning curve. Also, you won't be able to backport MPL11 to MPL because I diverged from the MPL in a rather major way by using lazy metafunctions in MPL11. They are more composable and you also don't have to write "typename" everywhere, but it breaks backward compatibility pretty severely. As a final note: if you have comments, doubts or other thoughts about Hana, please express them by either posting on this list or (even better) opening a GitHub[2] issue. If I know what people need, I can make sure that Hana satisfies them properly. I will be asking for an informal review shortly, so stay tuned. Regards, Louis [1]: http://ldionne.github.io/hana [2]: https://github.com/ldionne/hana