import std.stdio; typedef int num = 42; version (A) { void pow(alias b)() { writefln("full ", b); } void pow(num b)() { writefln("num ", b); } void pow(int b)() { writefln("int ", b); } } else version (B) { void pow(num b)() { writefln("num ", b); } void pow(alias b)() { writefln("full ", b); } void pow(int b)() { writefln("int ", b); } } else version (C) { void pow(num b)() { writefln("num ", b); } void pow(alias b)() { writefln("full ", b); } } else { static assert(false, "Provide version"); } void main() { num wyk = 22; pow!(wyk); } /* A: full 22 B: num 0 (why 0?, should be 22, eventually 42) C: ./po.d(22): template instance pow!(wyk) matches more than one template declaration, pow(num b) and pow(alias b) ./po.d(22): Error: import has no effect in expression (pow!(wyk)) Note: in A, B template "int" isn't used! So probably 3 bugs. When compiled without version block (leaving version B): num 22 */
http://digitalmars.com/d/template.html > > Determine which is more specialized is done the same way as the C++ partial ordering rules. > I'm unsure how C++'s rules would apply to the alias parameters and thus the specialization but I doubt that D shoud behave dependent on the template declaration order.
Just tested in newer compiler, same behaviour. (1.004, and 1.039)
Please keep the version setting at the oldest, not the newest, known version which exhibits the bug.
I recently retested this code in DMD 2.032: a918.d: ----- import std.stdio; typedef int num = 42; version (A) { void pow(alias b)() { writefln("alias %d", b); } void pow(num b)() { writefln("num %d", b); } void pow(int b)() { writefln("int %d", b); } } else version (B) { void pow(num b)() { writefln("num %d", b); } void pow(alias b)() { writefln("alias %d", b); } void pow(int b)() { writefln("int %d", b); } } else version (C) { void pow(num b)() { writefln("num %d", b); } void pow(alias b)() { writefln("alias %d", b); } } else { static assert(false, "Provide version"); } void main() { num wyk = 22; writeln("calling num wyk=22?"); pow!(wyk)(); writeln("calling int=4?"); pow!(4)(); uint x = 333; writeln("calling alias=x=333?"); pow!(x)(); } ----- It looks it behaves much better than original bug report: ------ baryluk@sredniczarny:/tmp$ dmd2 -version=A -w a918.d ; ./a918 calling num wyk=22? num -1077524476 calling int=4? int 4 calling alias=x=333? alias 333 baryluk@sredniczarny:/tmp$ dmd2 -version=B -w a918.d ; ./a918 calling num wyk=22? num -1081977116 calling int=4? int 4 calling alias=x=333? alias 333 baryluk@sredniczarny:/tmp$ dmd2 -version=C -w a918.d ; ./a918 calling num wyk=22? num -1076793804 calling int=4? alias 4 calling alias=x=333? alias 333 baryluk@sredniczarny:/tmp$ ----- We have the same behaviour regardles of version. In version C int properly uses "alias" template. Order of templates doesn't metter. Removing or leaving "version" blocks, doesn't change behaviour. But here we also see regression. num is not passed correctly. Even after removing "version" blocks, and leaving only "B" part. It also doesn't print any "0" or "42", or desired "22", but some random negative number.
I tested it today on 2.039 and regression dissapered, now all 3 versions give exactl the same correct answers: $ dmd2 -version=B -w a918.d ; ./a918 calling num wyk=22? num 22 calling int=4? int 4 calling alias=x=333? alias 333 $ It can be closed now I think, but still I will want to test it in DMD 1.x. Anyone knows what changes in compiler possibly made all this fixes, regression and fixes? I can try historical version and check which have what behaviour. I would not want to close error because it dissapered by random chance :)
(In reply to comment #5) > I tested it today on 2.039 and regression dissapered, now all 3 versions give > exactl the same correct answers: > > $ dmd2 -version=B -w a918.d ; ./a918 > calling num wyk=22? > num 22 > calling int=4? > int 4 > calling alias=x=333? > alias 333 > $ > > It can be closed now I think, but still I will want to test it in DMD 1.x. > > Anyone knows what changes in compiler possibly made all this fixes, regression > and fixes? I can try historical version and check which have what behaviour. > I would not want to close error because it dissapered by random chance :) It was fixed in 2.033,2.034, or 2.035 (works in 2.035, fails in 2.032). Many compiler structural problems were fixed around that time, so we can expect many bugs to be fixed. It still fails in D1, so cannot be closed yet. But I've put 'D1 only' in the title.
Not a spec issue.
(In reply to comment #5) > It can be closed now I think, but still I will want to test it in DMD 1.x. Closing as 1.x is discontinued. > Anyone knows what changes in compiler possibly made all this fixes, regression > and fixes? I can try historical version and check which have what behaviour. > I would not want to close error because it dissapered by random chance :) If you still would like to know, let me know and I'll do a "progression" test :)