Re: [boost] [metal] Feature Complete - Request for Feedback

Subject: Re: [boost] [metal] Feature Complete - Request for Feedback
From: Bruno Dutra (brunocodutra_at_[hidden])
Date: 2017-02-21 13:03:26

On Tue, Feb 21, 2017 at 10:53 AM, Hans Dembinski <hans.dembinski_at_[hidden]>
wrote:
>
> 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