Re: [boost] [MPL] A Proposal

2016-03-02 15:03 GMT-03:00, Edward Diener :

On 3/2/2016 12:23 PM, Bruno Dutra wrote:

...

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?

No. Any code using undocumented parts of a Boost library, or undocumented behavior which just happens to work with some release of some Boost library, is on its own. That can't be the concern of a library developer IMO.

However the responder has a good point that you need to be thorough in testing any change to Boost.MPL since it is such a core library of Boost. If you need help in testing MPL in an environment which may be difficult for you to replicate don't be afrad to ask on this mailing list.

Thank you Edward. No testing is too much testing, I’ll make sure this endeavour doesn’t turn into a fiasco. Regards, Bruno Dutra