Bug 12020 – Instantiating a template struct with equivalent const and enum arguments creates two types.

Status
RESOLVED
Resolution
DUPLICATE
Severity
normal
Priority
P2
Component
dmd
Product
D
Version
D2
Platform
All
OS
All
Creation time
2014-01-28T14:48:00Z
Last change time
2014-01-28T22:53:05Z
Assigned to
nobody
Creator
mason.b.mcgill

Comments

Comment #0 by mason.b.mcgill — 2014-01-28T14:48:33Z
This took me quite a few hours to figure out, and I can't think of any reason this would be desired behavior: //===========================================================================// import std.stdio; struct S(int n) {} void main() { enum e = 1; const c = 1; writeln(is(S!e == S!e)); // true. writeln(is(S!c == S!c)); // true. all good so far... writeln(is(S!e == S!c)); // false. that seems buggy... writeln(is(S!e == S!(cast(int) c))); // true. now that just can't be right. } //===========================================================================// Unless I'm missing something, the expected behavior is to create a single type.
Comment #1 by stanislav.blinov — 2014-01-28T15:26:11Z
typeof(e) == int - an underlying type of an enum. typeof(c) == const(int). Hence two distinct types.
Comment #2 by mason.b.mcgill — 2014-01-28T15:34:42Z
(In reply to comment #1) > typeof(e) == int - an underlying type of an enum. > typeof(c) == const(int). > > Hence two distinct types. Right--so that should yield two distinct template instances if you were parameterizing by type, like this: struct S1(T) {} but my example involved parameterizing by value, like this: struct S1(int n) {} Since the value of `cast(int)(e)` and `cast(int)(c)` are the same, shouldn't the two types be the same? Also, writeln(S1!e()); // prints the same output as writeln(S1!c()); // which is pretty confusing if they're not the same type.
Comment #3 by stanislav.blinov — 2014-01-28T15:45:37Z
Oh, hmm... Didn't think it through. Yeah, that seems odd indeed.
Comment #4 by yebblies — 2014-01-28T22:31:26Z
This looks like the same thing as issue 3467 - which is strange because that was fixed. Kenji?
Comment #5 by k.hara.pg — 2014-01-28T22:53:05Z
(In reply to comment #4) > This looks like the same thing as issue 3467 - which is strange because that > was fixed. Kenji? No. This is a dup of issue 7469. *** This issue has been marked as a duplicate of issue 7469 ***