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<l3, metal::number<3>>) 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<typename l, typename v> using append = join<l, list<v>>; is perfectly SFINAE friendly template<typename l, typename v> struct append : join<l, list<v>> {}; 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