Re: [boost] About all these metaprogramming libraries

Subject: Re: [boost] About all these metaprogramming libraries
From: Deniz Bahadir (dbahadir_at_[hidden])
Date: 2017-03-20 14:40:45

Am 19.03.2017 um 23:00 schrieb Michael Caisse via Boost:
> On 3/19/17 12:31, Bruno Dutra via Boost wrote:
>> On Sun, Mar 19, 2017 at 7:43 PM, Oswin Krause <
>> Oswin.Krause_at_[hidden]> wrote:
>>
>>> On 2017-03-19 17:13, Bruno Dutra via Boost wrote:
>>>
>>>> On Sun, Mar 19, 2017 at 4:22 PM, degski via Boost <boost_at_[hidden]>
>>>> wrote:
>
> <snip features and criticisms of various libraries>
>
>>
>> You've pretty much described Metal, except that Metal requires lists to be
>> specializations of metal::list, but that is far from a shortcoming, in fact
>> there is a very good reason behind that design choice.
>>
>
> <snip more things why-I-designed-my-library-this-way>
>
> Here is a suggestions. I don't think this thread is the place for the
> authors to explain the benefits of their design/implementation/usage.
> There will be a lot of time for that.
>
> In this thread, we are trying (as a community) to figure out the best
> approach to deal with multiple submissions of TMP libraries. Lets
> concentrate on that concern.

As mentioned before, I think some kind of comparison between such TMP 
libraries is required. A comparison between their features/concepts and 
especially the users' needs they try to address with these 
features/concepts.

For example, from a user's point of view I would pretty much like to see 
a "drop-in" replacement for Boost.MPL which compiles (much) faster (and 
uses less RAM doing so).
However, I am not really interested in using such a replacement by 
myself. I am instead interested in all existing Boost libraries that 
currently use Boost.MPL to "magically" become/compile faster (and use 
less RAM).

Of course, if all Boost-libraries that use Boost.MPL are actively 
maintained and their maintainers would apply internal changes so that 
these libraries would use another (faster) TMP library (e.g. Boost.Hana 
or what might be adopted next), that would be fine, too.
However, it probably is less work for the maintainer to only adjust some 
includes and maybe some typedefs to use a "drop-in" replacement instead 
of changing a lot of code to use another TMP library which is completely 
different from Boost.MPL.

>
> Don't worry ... there will be plenty of opportunity for critique and
> defense  (o;
>
> michael
>

Just my "user's view".

Deniz