On Feb 23, 2017 00:12, "paul via Boost"
Ideally, it would be nice if it supported gcc 4.6(even only
partially), as I would use it in my Tick library and get rid of my
homebrew metaprogamming. However, I know that might be a lot of
work since gcc 4.6 doesn’t have template aliases.
Sadly without alias templates there's not much I could do :(
Well on gcc 4.6 inheritance can be used instead of an alias, but then
you would need an evaluation step, like:
METAL_EVAL(metal::drop>)
And then the library would need to apply these evaluations internally
as well. I don't know know if you would accept a PR with changes to
support gcc 4.6 or not. Of course the first thing is to support for gcc
4.8 and then we could move backwards toward 4.7 and then 4.6.
For a long time Metal was lazy just like you describe, so I can tell you
from experience that it's not that simple. There are many reasons why, but
2 are most significant:
1. This might not be obvious at first, but while
template
using append = join;
is perfectly SFINAE friendly
template
struct append : join {};
is not.
2. Alias templates don't introduce new entities that has to be
instantiated, that is why one can't pattern match them. That means they are
very lightweight for the compiler and the main reason why Metal can be so
fast. This is most obvious to see in the implementations of metal::reverse,
metal::rotate, metal::accumulate, which employ a very clever trick by Odin
Holmes, that exploits alias templates to implement recursive algorothms
that would otherwise be extremely slow using inheritance. You can watch his
talk here https://youtu.be/cuNMtdE699E
To make Metal lazy again, you have to essentially revert this PR:
https://github.com/brunocodutra/metal/pull/32
