Bug 4639 – Built-in primitive types cannot be used as template alias parameters

import std.stdio; template T(alias X) { } void main() { writeln(typeid(typeof(T!int))); } dmd 2.048 on linux produces an error for the above code. Error: template instance T!(int) does not match template declaration T(alias X) Built-in primitive types cannot be used as template alias parameters. Structs and classes work well.

This is not a bug. From the spec: "Alias parameters enable templates to be parameterized with any type of D symbol, including global names, local names, typedef names, module names, template names, and template instance names. Literals can also be used as arguments to alias parameters." Built-in types are not on that list.

(In reply to comment #1) > This is not a bug. From the spec: > "Alias parameters enable templates to be parameterized with any type of D > symbol, including global names, local names, typedef names, module names, > template names, and template instance names. Literals can also be used as > arguments to alias parameters." > > Built-in types are not on that list. Hmm.. I don't think so. "parameterized with any type of D symbol, including ..." Why are not built-in primitive types included in "any type of D symbol"? Is there any particular reason that user defined type names (like struct names) are allowed but built-in type names are not allowed? I think such a limitation is not natural. IMHO, If there is any good reason for the limitation, the phrase "any type of D symbol" should be removed from the spec. If there are no such reasons, then this should be considered as a bug.

(In reply to comment #2) > (In reply to comment #1) > > This is not a bug. From the spec: > > "Alias parameters enable templates to be parameterized with any type of D > > symbol, including global names, local names, typedef names, module names, > > template names, and template instance names. Literals can also be used as > > arguments to alias parameters." > > > > Built-in types are not on that list. > > > Hmm.. I don't think so. > > "parameterized with any type of D symbol, including ..." > > Why are not built-in primitive types included in "any type of D symbol"? > Is there any particular reason that user defined type names (like struct names) > are allowed but built-in type names are not allowed? I think such a limitation > is not natural. I basically agree with you, but syntactically, they are quite different, and it's an intentional decision by Walter. See for example bug 1341.

Still I could not get the reason. So, I posted a message to the mailing list to discuss this.

This spec is way to sh... I mean incomplete to interpret it literally. Also it is known that the spec is downright incorrect in many cases. I don't know why you would close this bug as invalid just because of the spec text. Also it's very inconsistent to exclude built-in types. About it being intentional by Walter: he actually fixed the mentioned bug 1341 and didn't close it as invalid. Finally, it's a D1 problem too.

>It's exactly the same issue as: typeof(int) is not legal.(In reply to comment #5) > This spec is way to sh... I mean incomplete to interpret it literally. Also it > is known that the spec is downright incorrect in many cases. I don't know why > you would close this bug as invalid just because of the spec text. NO. I requested Walter to make this change, and he rejected this before. It is definitely NOT a bug. A built-in type is not a D symbol. > Also it's > very inconsistent to exclude built-in types. About it being intentional by > Walter: he actually fixed the mentioned bug 1341 and didn't close it as > invalid. No, *I* changed the description of the bug after discussion with Walter. It was originally "typeof(int) should probably be legal". > Finally, it's a D1 problem too. No it isn't. It's an enhancement which would break existing code.

(In reply to comment #6) > NO. I requested Walter to make this change, and he rejected this before. It is > definitely NOT a bug. A built-in type is not a D symbol. That's seriously stupid. Just another un-orthogonal feature that causes programmers headaches? > No it isn't. It's an enhancement which would break existing code. How?

I can't believe the limitation is deliberate. Please remove it if technically possible. Now the poor coder is forced to practice nonsense like: template Foo(A...) if (A.length == 1) {}