Dear Bruno,
What I do however wonder is, where does it fit in with MPL, Fusion and especially Hana? If you could give an overview of where your library is compared to those, you probably increase the support for your library.
That is a very valid concern and I wondered myself whether there was space for Metal in Boost for quite a while, before finally deciding to put this proposal forward.
It basically boils down to whether template metaprogramming (TMP) is still useful to modern C++, given decltype and the paradigm shift it enables, which is very well explored by Hana. I believe that yes, TMP has its unique use cases, mainly because:
* it scales much better in terms of both compile time and memory usage on all major compilers. To convince yourself, just check metaben.ch and be sure to play with the 'subtract baseline' switch; * It integrates nicely with standard type_traits and utilities; * It draws a clear line between type-level and value programming, which improves readability when the goal is to trigger SFINAE and drive overload resolution.
I am on the skeptical side. I just learned boost::mpl and boost::fusion to implement compile-time computations for my proposed boost.histogram library, so I am by no means an expert on meta-programming. Nevertheless, I was positively surprised how fast I made progress with these libraries once I overcame my general attitude of "TMP is weiiiiird". The structural similarity of boost::mpl with the STL eased the learning curve a lot. At first glance (I am looking at the code in the section "In a Glimpse" of your documentation), I don't see much syntactic difference to boost::mpl, could you elaborate on the differences? It seems you mostly you drop the trailing ::type, because you use alias templates. I like your metal::lambda, I am not sure if boost::mpl has that. If not, one could probably add it to boost::mpl. I suppose my big question is this: can't you just merge your ideas/improvements into boost::mpl? With ifdefs you could enable C++14 features like templated aliases when they are available. Even more so, it should be possible to merge your speed improvements into boost::mpl. I also looked at your benchmarks and they are a bit confusing. I am mostly interested in how your lib compares to the mpl, but not all benchmarks have mpl data, and those that have (see at or count_if) only use up to 50 elements. Is that a hard limitation of the current mpl implementation? I am looking forward to the comments from the authors of boost::hana and boost::mpl. Best regards, Hans