Re: [boost] [MPL] A Proposal

Subject: Re: [boost] [MPL] A Proposal
From: edouard_at_[hidden]
Date: 2016-03-01 10:36:17

> 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.

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.

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.

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.

This is of course not an opinion on the quality of your Metal library, just a comment on its relation with Boost.MPL.

Kind regards.

--Edouard