Subject: Re: [boost] About all these metaprogramming libraries
From: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2017-03-18 23:04:34
2017-03-18 22:49 GMT+01:00 Vicente J. Botet Escriba via Boost <
> Le 18/03/2017 Ã 21:32, Louis Dionne via Boost a Ã©crit :
>> Dear Boost,
>> We've seen two metaprogramming libraries ask for a formal review on the
>> 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
>> for how we're going to deal with this.
>> Before going further, I'd also like to clear something out. Some people
>> asked whether "classic" metaprogramming libraries still had their place
>> given that we now have Hana. 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
>> 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
>> 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
>> 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
>> 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
>> 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
>> 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?
>> If there were several proposals, we could review all of them together. We
> already did that for the thread/futures proposals.
> I believe that some of the things we need to answer are:
> * do we want (can) to use as (HOMF) high-order meta-functions? if we nedd
> them at all). IIUC, Peter library doesn't works with HOMFs.
> * do we want a Hana style with "concepts" and with customizations? Do we
> want other data type than type lists? IIUC Peter's library works only with
> template aliases as data types and almost variadic class template with type
> parameters is a good candidate for a type list (even std::variant :( )
> * do we need lazy evaluation?
> * do we need lambdas?
> * do we want a C++11/C++14/C++17 library?
> .... other you can think of.
Maybe, during the process, to get the additional insight, we sould request
of each of the candidates to compare the librearies with one another. They
are experts in the domain, and should be able to quickly identify different
tradeoffs taken by deiifferent libraries.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk