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 ***