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-20 21:59:44

On Mon, Feb 20, 2017 at 10:06 PM, Klemens Morgenstern via Boost <
boost_at_[hidden]> wrote:

> From a first look at it, this looks quite awesome.

Thanks!

> 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.

Essentially I advocate you are better off using TMP if you are either
dealing with a couple of dozens to thousands of elements or all you want is
to constrain types to implement concept like requirements for functions
templates.

Now, since we still need TMP, the following question is whether MPL fits
our needs. I posit that it can't possibly for several reasons, the most
apparent being:

* it is _very_ verbose, mainly because the necessary tools, such as alias
templates, weren't available at the time it was developed;
* it doesn't scale at all, because it relies on the preprocessor to emulate
variadic templates, which is orders of magnitude slower and more memory
hungry than pure TMP on a given compiler. Again you don't have to take my
word for it, just browse metaben.ch.

Finally, comparing Metal specifically to Hana, I believe it has some
potential advantages besides what I've mentioned so far:

* Metal is much lighter conceptually than Hana and in fact relies on only a
couple of very simple concepts that are precisely defined early in the
documentation, which are sufficient to formally describe every construct
that the library provides [1]
* being fined tuned for heterogeneous programming more than anything else,
Hana happens to also support type level computations, while Metal is
specifically designed for that end and is thus able to provide better tools
in my opinion.

> On a less important note: I'm not sure about the name, I immediately
> thought of bare-metal C++ when I heard that. But that might just be me.

To be honest neither was I when I picked it, however, after 2 years of
development I learned to like it and started naming a couple of offspring
projects after the same semantic domain, for example Alloy [2], where Metal
is used as a backend to heterogeneous algorithm (it is very early in its
development, but one can already see some use cases for Metal).

[1]: http://brunocodutra.github.io/metal/#concepts
[2]: https://github.com/brunocodutra/alloy

Best regards,
Bruno