
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@ruhr-uni-bochum.de> wrote:
On 2017-03-19 17:13, Bruno Dutra via Boost wrote:
On Sun, Mar 19, 2017 at 4:22 PM, degski via Boost
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