CTFE vs. traditional metaprogramming

[language_fan]

Mon, 12 Oct 2009 14:01:59 +0200, Don thusly wrote:

> language_fan wrote:
>> As far as I can tell there is no reason why you cannot call templates
>> from a CTFE code. Your code above has two problems: a) it never
>> terminates
> 
> It wasn't meant to be a compilable example.
> 
> b) due to some lookup problem the compiler gets confused, this
>> has nothing to do with CTFE not being able to call templates - for
>> instance this works:
>> 
>>> template A(int X) { enum int A = 2+1; }
>>>
>>> int B(int X) { return A!(X) + 1; }
> 
> You're seeing a few bugs there. In the template X isn't a constant, it's
> an alias (that is NOT in the spec, bug 2962). If you try adding a
> "static assert(X!=2)", you'll find it's not a constant. It will let you
> write:  enum int A = X + 1; but that's bug 2414.
> 
> The rule is, any CTFE function must also be evaluatable at run-time.
> Templates cannot be instantiated at run-time. Therefore templates cannot
> be instantiated in CTFE.

Ah, I see what you meant now. Indeed, there are some open issues wrt how 
these things should work. Basically your original example could be 
compilable, even when there is a dependency on a runtime variable, if a 
proper macro system was available. The compiler could just copy'n'paste 
the template body to the point where it is being instantiated. This all 
happens in the static part of the function declaration. I have no idea 
how to fix the template system -- I'm not too happy with the idea of 
extending parametric polymorphism this much. A distinct AST level macro 
system would make more sense.