Boost logo

Boost :

Subject: Re: [boost] [MPL] A Proposal
From: Jens Weller (JensWeller_at_[hidden])
Date: 2016-02-29 04:37:30

> Gesendet: Montag, 29. Februar 2016 um 00:17 Uhr
> Von: "Bruno Dutra" <brunocodutra_at_[hidden]>
> An: boost_at_[hidden]
> Betreff: [boost] [MPL] A Proposal
> Dear Community,
> About a year ago today, there was a proliferation of threads [1][2][3] in
> this mailing list concerning the future of Boost.MPL, or even whether it
> had a future at all, and opinions diverged widely on the matter. Many have
> expressed concerns about the fact Boost.MPL was long outdated and proposed
> major changes to open path for modernization, while some others argued
> against it, fearing unexpected and disastrous side-effects could propagate
> throughout the rest of Boost. A few questioned if it was worth it at all to
> spend any further resources on Boost.MPL given the fact new alternatives
> were coming up, such as Boost.Hana, which departed entirely from template
> metaprogramming, yet some argued TMP remained a competitive alternative for
> type computations in C++14 as it has been demonstrated by Peter Dimov in
> his impressive articles [4] on modern TMP.
> Amidst all this, a proposal by Robert Ramey [5] caught my attention and
> inspired me to develop what I call Metal [6], a template metaprogramming
> library designed on the same core principles as Boost.MPL, but written from
> the very beginning to take full advantage of C++11. Metal was not designed
> to be a strict drop in replacement for Boost.MPL though, it was rather
> meant to be regarded as a modern version of Boost.MPL's original API,
> diverging only where it could really benefit from modern C++ and that
> essentially means gains of several orders of magnitude in performance** and
> lower memory consumption. At this point Metal is very close to where I
> originally intended to bring it and I think it's time I gauge interest from
> the community on a modest proposal I've been maturing along the past year.
> 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.
> This proposal also overcomes the problem of dealing with the
> maintainability of Boost.MPL, since it provides a way for smooth transition
> from legacy hacks required by ancient compilers into a cleaner and easier
> to maintain C++11 codebase, besides avoiding any breaking changes within
> existing code in the process. Furthermore, should this proposal make it
> into Boost, I would be naturally willing to take responsibility for the
> maintenance of Boost.MPL, which AFAIK has been maintained by the CMT for
> quite some time now, often with limited resources.

Whats the difference between your metal library and the Brigand library by Edouard Aligand and Joel Falcou, also written for a similar purpose: to replace boost.MPL?
Do you compile as fast as Brigand?


Jens Weller


Boost list run by bdawes at, gregod at, cpdaniel at, john at