Re: [boost] About all these metaprogramming libraries

Subject: Re: [boost] About all these metaprogramming libraries
From: Paul Fultz II (pfultz2_at_[hidden])
Date: 2017-03-18 23:43:34

> On Mar 18, 2017, at 2:32 PM, Louis Dionne via Boost <boost_at_[hidden]> wrote:
> 
> Dear Boost,
> 
> We've seen two metaprogramming libraries ask for a formal review on the list
> recently. I expect a third (Brigand) might join the party soon, and maybe
> even a fourth (Eric Niebler's meta). I think it would be wise to have a plan
> for how we're going to deal with this.
> 
> Before going further, I'd also like to clear something out. Some people have
> asked whether "classic" metaprogramming libraries still had their place
> given that we now have Hana.

Of course, there is a place for portability. Hana doesn’t work with gcc 4.8 nor gcc 5 nor MSVC. So if a library would like to support those compilers and utilize a library to handle metaprogramming or heterogeneous sequences, it would be nice to have an alternative modern solution instead of having to continue to use Fusion or MPL.

> As the author of Hana, I think the answer is
> yes. While Hana is (IMHO) easier to use and more powerful, it also has an
> important shortcoming. Hana is too slow when dealing with very large inputs.
> This is due to the fact that it can also handle values, which is much
> heavier than dealing with types only. This can be alleviated to some extent,
> but the truth is that our execution model (the compiler) simply has to do
> more work when handling values.
> 
> Hence, I think Boost does need a modern classic TMP library to handle these
> cases where a library writer needs to handle gigantic type lists. I think
> marketing such a library as an advanced tool for library writers would be a
> service to the overall C++ community, but that's an orthogonal concern.
> 
> However, Boost needs one such library, not four. I think we can't just do 4
> reviews and include all the libraries that pass in Boost; that would be a
> huge disservice to our users, who will be left with the burden of choosing.
> Heck, if we can't even make our mind, how can they?
> 
> So, how do we pick? Have we ever been in a similar situation where we have
> multiple competing libraries solving _exactly_ the same problem?

It would be nice to see better collaboration between authors to build an unifying metaprogramming library, rather than competing against each other. Of course, this can be somewhat difficult as they have different fundamental concepts.

Paul