Bug 14820 – Templates not reevaluated inside static loop unrolling

The summary text might be wrong as I'm not sure what the root cause is. The template is just evaluated on the first loop even though the underlying value changes: The following code: template TypeOf(alias T) { pragma(msg, "TypeOf evaluated with ", T.stringof); alias TypeOf = typeof(T); } void main() { import std.typetuple; foreach(type; TypeTuple!(int, short)) { type a; pragma(msg, "loop:") pragma(msg, " type: ", type); pragma(msg, " a: ", typeof(a)); alias t = TypeOf!a; pragma(msg, " TypeOf: ", t); } } Produces the following output: loop: type: int a: int TypeOf evaluated with a TypeOf: int loop: type: short a: short TypeOf: int Notice that the TypeOf template is only evaluated for the first pass through the loop.

I think that's a duplicate of https://issues.dlang.org/show_bug.cgi?id=9748

(In reply to Mathias LANG from comment #1) > I think that's a duplicate of https://issues.dlang.org/show_bug.cgi?id=9748 Yes, looks very similar (although on dynamic values rather than compile-time values). C# had a very similar issue in version 3, but it has since been changed to capture the current loop variable rather than the symbol that is reused. A breaking change, but even C#, which is very reluctant to change (more so than D), did it. I notice that issue was filed over two years ago. What is the reason for not fixing this? Avoiding breaking change (I consider it a bug though, and so did the C# team)? Or just the lack of manpower?

(In reply to simendsjo from comment #2) > (In reply to Mathias LANG from comment #1) > > I think that's a duplicate of https://issues.dlang.org/show_bug.cgi?id=9748 > > Yes, looks very similar (although on dynamic values rather than compile-time > values). C# had a very similar issue in version 3, but it has since been > changed to capture the current loop variable rather than the symbol that is > reused. A breaking change, but even C#, which is very reluctant to change > (more so than D), did it. > > I notice that issue was filed over two years ago. What is the reason for not > fixing this? Avoiding breaking change (I consider it a bug though, and so > did the C# team)? Or just the lack of manpower? Lack of manpower AND complexity of the issue (static foreach is an hack ATM).

*** This issue has been marked as a duplicate of issue 14831 ***