Bug 1341 – typeof(X) accepted, even if X is a type

Status
RESOLVED
Resolution
FIXED
Severity
normal
Priority
P2
Component
dmd
Product
D
Version
D1 (retired)
Platform
x86
OS
Windows
Creation time
2007-07-14T16:52:00Z
Last change time
2014-02-16T15:22:50Z
Keywords
accepts-invalid, spec
Assigned to
bugzilla
Creator
clugdbug
Blocks
1777

Comments

Comment #0 by clugdbug — 2007-07-14T16:52:03Z
According to the spec (in declaration.html), the argument to typeof() must be an expression. This is not currently enforced by DMD. In fact, it can be any type, except for builtin types which fail with a misleading error message. alias int foo; typeof(foo) a; // ok typeof(int) b; // FAILS: found ')' when expecting '.' following 'int' typeof(typeof(foo)) c; // ok, even though the argument is obviously a type. I think that the compiler's behaviour generally makes more sense than the spec (and I'm finding it to be useful behaviour). Enforcing the rule in the spec would mean the compiler would need to determine if 'foo' is a type name before issuing a syntax error --> violation of independence of syntax and semantic passes. So I suggest that the spec be changed to allow typeof(Type) to be legal, and to adjust the compiler to accept built-in types. eg, make typeof(int) synonymous with int.
Comment #1 by smjg — 2007-10-21T10:58:03Z
According to the spec, typeof(typeof(foo)) shouldn't compile. As you've probably noticed already, the syntax is Typeof: typeof ( Expression ) and this is parseable only as a type and not as an expression. I can see that there might be some generic programming use in defining typeof(X) == X if X is already a type. The only problem is that it isn't documented. But if what's in the brackets is already not parseable as an Expression, there's no benefit to writing it this way. As such, it's probably reasonable to disallow it as it would mean yet another ambiguity in the grammar.
Comment #2 by bugzilla — 2008-07-02T01:41:18Z
I agree with Stewart, neither should compile.
Comment #3 by clugdbug — 2008-07-02T02:10:45Z
So the resolution would be that: typeof(X) would generate an error late in the semantic pass if X turns out to be a type, rather than an expression?
Comment #4 by bugzilla — 2008-07-02T02:44:22Z
Yes.
Comment #5 by clugdbug — 2008-07-03T08:03:39Z
One thing worries me about this... in D1.0, a common metaprogramming idiom is "is(typeof(xxx))" For example, this compiles in D1.0: ------ static assert(!is(typeof(nonexistent))); ------ Lots of code (including BLADE, for example) will fail if that stops working. Please make sure that doesn't get broken in fixing this bug!
Comment #6 by smjg — 2008-07-03T09:03:40Z
How do you work that out?
Comment #7 by clugdbug — 2008-07-03T09:46:30Z
Changed the description of this bug in view of the discussion above. The fear I mentioned above is probably irrational.
Comment #8 by clugdbug — 2008-07-09T07:19:41Z
Fixed DMD1.032
Comment #9 by clugdbug — 2008-07-09T07:20:34Z
*** Bug 1777 has been marked as a duplicate of this bug. ***
Comment #10 by bugzilla — 2008-07-09T22:39:55Z
Fixed dmd 1.032 and 2.016