Re: [boost] [MPL] A Proposal

Subject: Re: [boost] [MPL] A Proposal
From: Joel FALCOU (joel.falcou_at_[hidden])
Date: 2016-03-02 14:06:25

On 02/03/2016 18:23, Bruno Dutra wrote:
> 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.

Some points there :

  - Brigand as library is on the road to be submitted to boost. But now, 
we need to make it more mature and complete. It's a valid question for 
us as at least 3 Boost Libraries developers asked us to do so so they 
can use it inside their library. Boost.Dispatch and Boost.SIMD, 
libraries I co-write, also use brigand internally.

  - Boost.MPL idioms from C++2003 are archaic by now. As Edouard pointed 
out, rewriting MPL in C++11 is a mere upgrade, a large effort for a 
meager gain. The road we choose to follow with Brigand was to provide a 
TMP library with updated idioms and so, an updated interface.

  - Compile time performances nowadays is probably the ONE issue people 
raise about complex (or even simple in some cases) template 
metaprogramming. To make TMP a day-to-day tool for average joe developer 
in the wild is to ensure that compile times are manageable. So I think 
focusing on CT-performance must be target #1 for any modern TMP library, 
hence our design choices in brigand.

  - We also figured out people want something between MPL and Hana. 
We're not in a process of being included in Boost for the sake of it but 
as said earlier, it's something we could do as the library matures.
Brigand is maybe rewritable later as something ont he side of Hana or 
even disappear as a bunch of wrappers to siplify some Hana constructs.
The paradigm shift induced by Hana is somethign to take into account.