On Tue, Feb 21, 2017 at 10:53 AM, Hans Dembinski
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. Great! So you'll be mind-blown by what Metal can do with the help of modern C++ features!
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.
Metal is purposefully designed to resemble MPL stripped of all the `typename`s and `::type`s, but their similarities end there. MPL was written some 15 years ago, at a time that compilers that actually handled templates correctly were scarce. If you peek at MPL's source code you will promptly realize that half of it is really working around broken compilers, the other half being emulating missing language features that were introduced only much later in C++11. That is actually the greatest feat of MPL, heck it was written even before C++03 was standardized! Fortunately we can kiss all that heroic hackery goodbye, now that we have access to variadic templates and template alias, along with the fact that compilers of this decade are not all that bad anymore. This gives Metal a lot of flexibility to address other issues that MPL couldn't tackle back then, such as scalability and ease of use.
I like your metal::lambda, I am not sure if boost::mpl has that. If not, one could probably add it to boost::mpl.
MPL has something functionally similar called quote, except that mpl::quote doesn't actually exist, because it couldn't possibly be implemented without variadic templates. What do exist are its numbered relatives, mpl::quote1, mpl::quote2, ..., up to mpl::quote15, each able to handle only metafunctions that take exactly that many arguments, with no support for variadic metafunctions whatsoever. This a great example of MPL's greatest shortcoming: there was no other option back then, but to enumerate every possible specialization of templates, which entails a _lot_ of code repetition and the most gruesome preprocessor hackery you'll ever see.
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.
It does sound like a good idea from the user's point of view since Metal looks so similar to MPL, but because they are so drastically distinct internally, merging them into a single library doesn't really make any sense. Fortunately, if you are coming from some legacy metaprogram, it is easy to incrementally migrate to Metal using the helper metal::from_mpl, but there is really no reason to ever use MPL anymore on a new project.
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?
Unfortunately that is indeed a hard limit of of Boost.MPL. Just like mpl::quote, everything else in MPL had to be implemented by enumerating every possible combination of arguments, which implies that some hard limit must have been chosen. That limit is 50 to sequence sizes and 15 to mpl::quote, mpl::apply and their friends. Metal doesn't have any theoretical limit and the number of arguments can easily reach the thousands in practice. Now I know that these arguments may sound a bit too abstract to someone not very experienced with template metaprogramming, but the advantages of modern C++ quickly become apparent when you try it out, so I invite you to give Metal a spin, so you can convince yourself.
I am looking forward to the comments from the authors of boost::hana and boost::mpl.
While the author of Hana is very active in the Boost community, it is unfortunately very unlikely that you'll hear from MPL authors in this mailing list nowadays. Regards, Bruno