Bug 9029 – Built-in types treated specially for alias parameters

DMD 2.060: template Foo(alias a){ } struct S{} alias S X; // ok alias int Y; // ok mixin Foo!S; // ok mixin Foo!int; // not ok The code should compile.

*** Issue 8491 has been marked as a duplicate of this issue. ***

I'm suffering from this problem too. Fix would be nice! :)

This is one of those perennial issues, that everybody discovers. Previous enhancement requests identical to this one include bug 1100, bug 3116, bug 4639. I remember requesting it once, as well. It goes back even further. Here's a discussion from July 2004 (template alias parameters were first implemented in Jan 2004, so this is the dawn of time): http://digitalmars.com/d/archives/digitalmars/D/6063.html Interestingly one thing which _was_ changed in D2 is that template alias parameters can now include expressions. Late in the history of D1, local variables were also added as template alias parameters. But still not basic types.

(In reply to comment #3) > This is one of those perennial issues, that everybody discovers. > > Previous enhancement requests identical to this one include bug 1100, bug 3116, > bug 4639. I remember requesting it once, as well. > > It goes back even further. Here's a discussion from July 2004 (template alias > parameters were first implemented in Jan 2004, so this is the dawn of time): > > http://digitalmars.com/d/archives/digitalmars/D/6063.html > > Interestingly one thing which _was_ changed in D2 is that template alias > parameters can now include expressions. Late in the history of D1, local > variables were also added as template alias parameters. But still not basic > types. There was a proposal recently on the NG suggesting builtin types should have entries in the symbol table. Sounded fairly reasonable.

(In reply to comment #4) > There was a proposal recently on the NG suggesting builtin types should have > entries in the symbol table. Sounded fairly reasonable. Yeah, this is what the dragon book suggests as well.

(In reply to comment #5) > (In reply to comment #4) > > > There was a proposal recently on the NG suggesting builtin types should have > > entries in the symbol table. Sounded fairly reasonable. > > Yeah, this is what the dragon book suggests as well. Huh? There is no technical difficulty whatsoever, AFAIK it was _never_ thought to be difficult to implement.

(In reply to comment #6) > (In reply to comment #5) > > (In reply to comment #4) > > > > > There was a proposal recently on the NG suggesting builtin types should have > > > entries in the symbol table. Sounded fairly reasonable. > > > > Yeah, this is what the dragon book suggests as well. > > Huh? There is no technical difficulty whatsoever, AFAIK it was _never_ thought > to be difficult to implement. When did the difficulty come in to question? Something to do with this 'dragon book' that I don't understand?

(In reply to comment #7) > When did the difficulty come in to question? Something to do with this 'dragon > book' that I don't understand? I don't know. There's a book called "Compilers: Principles, Techniques, and Tools" which is also referred to as "the dragon book". It's basically the bible for compiler construction. If I recall correctly, Walter has said that DMD doesn't contain any fancy code, just the standard algorithms present in the dragon book. http://en.wikipedia.org/wiki/Compilers:_Principles,_Techniques,_and_Tools

I ran into this bug again today twice. In one case the alias was to receive 'void' which it didn't like either.

(In reply to comment #7) > (In reply to comment #6) > > (In reply to comment #5) > > > (In reply to comment #4) > > > > > > > There was a proposal recently on the NG suggesting builtin types should have > > > > entries in the symbol table. Sounded fairly reasonable. > > > > > > Yeah, this is what the dragon book suggests as well. > > > > Huh? There is no technical difficulty whatsoever, AFAIK it was _never_ thought > > to be difficult to implement. > > When did the difficulty come in to question? Something to do with this 'dragon > book' that I don't understand? The comments you guys have made indicated to me that you don't realize that the reason this isn't part of the language is simply because Walter has seen it as undesirable. (Not that it would make the compiler ugly or complicated or anything like that).

(In reply to comment #10) > The comments you guys have made indicated to me that you don't realize that the > reason this isn't part of the language is simply because Walter has seen it as > undesirable. (Not that it would make the compiler ugly or complicated or > anything like that). Ah okay, yeah I have no idea about the implementation, just commenting on a conversation I saw which sounded sensible :) It'd be nice to have some sort of fix regardless. Any changes to make D more orthogonal in general are surely good.

Elevating importance to normal based on: http://forum.dlang.org/post/[email protected]

Related: issue# 16496 If the solution to this is to treat built-in types as symbols (as opposed to special casing alias template parameter so that they work with built-in types in spite of them not being symbols), then that issue will be fixed as well.

As I flashed up on the screen at DConf: enum NameOf( alias Symbol ) = Symbol.stringof; pragma( msg, NameOf!int );

@FeepingCreature created dlang/dmd pull request #9769 "Fix issue 9029: make types match to alias template parameters with priority MATCH.convert." fixing this issue: - Fix issue 9029: make types match to alias template parameters with priority MATCH.convert. https://github.com/dlang/dmd/pull/9769

dlang/dmd pull request #9769 "Fix issue 9029: make all types (including basic) match to alias template parameters with priority MATCH.convert." was merged into master: - 3e22ae81b18d6caa57865aaa3e0d48ea6678903a by FeepingCreature: Fix issue 9029: make types match to alias template parameters with priority MATCH.convert. https://github.com/dlang/dmd/pull/9769

dlang/dmd pull request #12339 "[dmd-cxx] Backport fixes and trivial features from upstream dmd" was merged into dmd-cxx: - b1eeca4a22011de5c361db37eff9ab6836db313e by FeepingCreature: [dmd-cxx] Fix issue 9029: make types match to alias template parameters with priority MATCH.convert. https://github.com/dlang/dmd/pull/12339

dlang/dmd pull request #12345 "[dmd-cxx] Reapply Fix issue 9029: make types match to alias template parameters with priority MATCH.convert." was merged into dmd-cxx: - f34e3f78c5454360fac46d974d21317a464425ac by FeepingCreature: [dmd-cxx] Reapply Fix issue 9029: make types match to alias template parameters with priority MATCH.convert. https://github.com/dlang/dmd/pull/12345