2016-03-01 12:36 GMT-03:00, edouard@fausse.info
As a modern approach to the same task that Boost.MPL was meant to address, I don't believe Boost would benefit at all from yet another TMP library that would essentially compete with Boost.MPL and even Boost.Hana in some cases, specially as maintainers of older code that depends on Boost.MPL would have to go through major refactoring efforts in order to benefit from such an addition to Boost. I would like to propose something different instead.
My proposal is to make Metal officially into a new revision of Boost.MPL's API, essentially MPL2 as the original proposal by Robert Ramey put it, merging both into one single TMP library. The idea would be to provide a thin proxy for the current Boost.MPL API which would have two backends configurable by preprocessor switches: the original implementation and a another one based on Metal. This way older code using Boost.MPL could see immediate gains on performance by selecting the newer backend on supported compilers, while at the same time legacy code maintained on older compilers could still rely on Boost.MPL's impressive ability to run virtually anywhere. On the other hand, newer projects interested on pure type computations would have the newer API entirely available to them.
I do not think you should focus too much on Boost.MPL. Boost.MPL is C++ 03 metaprogramming library. If you need a C++11/14/17 TMP, then you need another library.
In Brigand we looked at Boost.MPL in terms of features, like, you should be able to do everything you do with Boost.MPL with Brigand, but we didn't look at *how* it's done with Boost.MPL, because it doesn't matter. C++ 11 is a different language than C++ 03. It would be like writing a C++ 11 Json library and bothering about how it's been implemented in Python.
I believe we concur then. I should stress that Metal is an entirely new TMP library written from scratch to take advantage of everything C++11 has to offer, no restrictions imposed. Metal’s only relation to Boost.MPL is the fact it has been designed so as to _ look_ very much like Boost.MPL from the point of view of the user, that is, it is built around similar concepts and provides roughly the same metafunctions, so, in this sense, I argue it is a natural successor to Boost.MPL.
If you want to change a single line of Boost.MPL or add a wrapper you will spend a lot of time in back testing and will never be 100% sure it's retro-compatible. A lot of critical code, out there, depends on Boost.MPL and I don't think it's a good thing to add friction in the upgrade path. I also submit that Boost library authors currently using Boost.MPL will go after you with pitchforks if you break anything.
Having a proxy that switches backend transparently looks like a good idea but is, in my opinion, very hard to do for little to no benefit.
I very much share your concern. It poses a considerable risk to inpact in any way a core library such as Boost.MPL that has been in use for over a decade now and that is why I turn to the community for discussing this proposal. I do believe it is possible to make sure the alternative implementation of Boost.MPL honours every requirement of its documentation with reasonable confidence, since it is easier for a pure functional language, but it is also possible that some code out there still breaks due to their reliance on undocumented behaviour (been there done that). Now should Boost care for such cases?
You might be surprised to learn than in real-life project switching from Boost.MPL to a faster "more modern" MPL doesn't yield any speed improvement unless you change the way your use that MPL. I am speaking from experience because when we switched from Boost.MPL to Brigand in quasardb, we had to change a certain number of things to see any impact in terms of compilation speed. Whereas if you compile side by side a Boost.MPL program and a Brigand program there is easily one order of magnitude in speed gain with Brigand.
That is not true in general, for it depends on how Boost.MPL is used. More specifically, if sequences are explicitly folded, iterators are explicitly tracked or any other mandatorily recursive algorithm is used, then I agree with you that using Metal as a backend for Boost.MPL would only bring marginal improvements at most. However, if mostly algorithms that may be somehow expressed in terms of variadic template expansion are used, such as transform, find, remove, replace, contains, partition, etc., then most surely dramatic improvements would be perceived. Since you mentioned performance, I would like to clarify that Metal was not designed to be the fastest TMP library out there, nor it is advertised as such, rather I pose that it is just fast enough for mainstream metaprogramming and that’s already a couple of orders of magnitude faster than Boost.MPL in most cases. That means I actively avoided such optimizations as fast tracked recursion and unrolling, which tend to demand additional template specializations, which clutter the code base and thus impair clarity and maintenance. My goals were instead make sure Metal was as easy as possible to maintain and that is why I believe it is a good fit for Boost. I invite you and everyone else to briefly browse through the source code [1], so you can see I did try hard to keep it simple and easy to understand.
I think if people want to do C++ 11/14/17 TMP they might as well start with new principles and I don't think it's worth annoying Boost.MPL users with evolution that, in the end, might not be as substantial as you infer.
The other advantage of not extending/modifying Boost.MPL is that nothing prevents you to progressively switch from one library to the other. For example, progressively migrate the code from Boost.MPL to Boost.Hana.
I designed Metal around the concept of TMP because I do believe it is expressive and cleaner when all one needs to do is manipulate some types, express a few concepts and trigger SFINAE accordingly. In other words, I consider TMP a feature, not a constraint.
This is of course not an opinion on the quality of your Metal library, just a comment on its relation with Boost.MPL.
I appreciate your comments and I hope I could clarify a few aspects regarding the design of Metal. [1]: https://github.com/brunocodutra/metal/tree/master/include/metal -- Bruno Dutra