Re: [boost] "Simple C++11 metaprogramming"

Subject: Re: [boost] "Simple C++11 metaprogramming"
From: Robert Ramey (ramey_at_[hidden])
Date: 2015-08-14 12:07:03

On 8/13/15 11:44 AM, Eric Niebler wrote:
> On 7/16/2015 10:35 AM, Robert Ramey wrote:
>> On 5/30/15 9:26 AM, Peter Dimov wrote:
>>> I've recently made the mistake to reread Eric Niebler's excellent "Tiny
>>> Metaprogramming Library" article
>>>
>>> http://ericniebler.com/2014/11/13/tiny-metaprogramming-library/
>>>
>>> which of course prompted me to try to experiment with my own tiny
>>> metaprogramming library and to see how I'd go about implementing
>>> tuple_cat (a challenge Eric gives.)
>>>
>>> Ordinarily, any such experiments of mine leave no trace once I abandon
>>> them and move on,
>>
>> We need a permanent place for stuff like this.
>>
>>> but this time I decided to at least write an article
>>> about the result, so here it is, with the hope someone might find it
>>> useful. :-)
>>
>>> http://pdimov.com/cpp2/simple_cxx11_metaprogramming.html
>>
>> This to me is incredible.  I worthy successor to Abraham's and
>> Gurtovoy's MPL book.  Clearly C++/11 is going to turnout to be a major
>> game changer with repercussions beyond what we can imagine now.
>
> AFAICT, Peter's code is basically a work-alike of my Meta library [^1]
> with one feature added (the ability to treat any template instance as a
> typelist), and one feature removed (metafunction classes and their
> associated utilities).

To me there is a fundamental difference between Peter's formulation and 
others such as yours, Hana, and others.

I see Peter's document as a "cheat sheet" which describes useful TMP 
idioms which are supported directly by C++.  It shows how far one can go 
with no library at all.  This is useful in a way that a TMP library is not.

a) It is extremely helpful as a learning tool.

b) It is very useful to one who needs just a little bit of TMP to get 
over some programming hurdle in the most direct and expedient manner.
If one includes one of these idioms in his code, you don't need to 
include a whole library with a lot of new conceptual overhead.  You just 
have to refer to the Simple C++/TMP document.

c) Adding some other library is a bigger deal.  It requires reference to 
more elaborate complete documentation which someone has to maintain. 
Once someone creates a library, they naturally want to inform it with 
some conceptual integrity.  This makes it better as a library, but then 
likely requires new concepts and more complete documentation and 
maintenance.

So I see Peter's Cheet sheet as complementing a library solution.  It 
helps users learn the concepts, provides solutions for many problems, 
but has not pretension to creating a "library".  Of course as people 
become more comfortable with TMP through the use of Peter's cheetsheet, 
some will eventually move on to creating some more complex metafunctions 
on their own and/or move to a more complete library solution.  In short 
- I see peter's work as complementing rather than competing with library 
solutions.

> I really believe losing metafunction classes is a significant loss --
> not so much because template template parameters are so awful (but they
> kind of are), but because all the functional composition utilities
> (bind, compose, curry, uncurry, on, etc.) are so incredibly useful. And
> also because core issue #1430 [^2] makes it impossible to handle
> variadic and fixed-arity template aliases uniformly.

Right - If you need this stuff - use a library.

> Meta's approach -- borrowed from the MPL -- of quoting template template
> parameters to turn them into metafunction classes (aka alias classes)
> puts the workaround for #1430 in one place so that it can be ignored and
> forgotten.

Which of course is the essence and motivation for creating a library. 
But Peter's document doesn't purport to be a library.  I realize that 
peter got sucked in to demonstrating how far one could take this - his 
ego got the best of him and this diluted his point.  The power of his 
document is not that it can do everything - it's that one can do a lot 
with zero conceptual overhead and very little investment.

> But in the end, Peter's and my thinking is pretty aligned wrt
> metaprogramming in C++11 and beyond.

I think we all agree that C++11+ has opened up lot's of unanticipated 
new territory in meta programming.

> [1]: https://github.com/ericniebler/meta
> [2]: http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#1430
>

Robert Ramey