Re: [boost] About all these metaprogramming libraries

Subject: Re: [boost] About all these metaprogramming libraries
From: Bruno Dutra (brunocodutra_at_[hidden])
Date: 2017-03-18 23:23:03

On Sat, Mar 18, 2017 at 10:49 PM, Vicente J. Botet Escriba via Boost <
boost_at_[hidden]> wrote:

> 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
>> 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. 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?
>>
>> 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.
>

To add to that list, we also need to ask ourselves

* do we need SFINAE friendliness?
* do we want to use pattern matching to extract data from concepts?

> However I see only one official proposal (mp11 - Peter Dimov), even if
> there are other interesting libraries (as Meta, Brigand).
> <http://lists.boost.org/mailman/listinfo.cgi/boost>
>

The formal submission of Metal is just a matter of formality and will
happen in the following days.

Bruno