Bug 14719 – Template instantiation parsed as C-style type cast

Status
RESOLVED
Resolution
INVALID
Severity
normal
Priority
P1
Component
dmd
Product
D
Version
D2
Platform
x86_64
OS
Linux
Creation time
2015-06-22T07:49:00Z
Last change time
2015-06-23T00:19:39Z
Keywords
diagnostic
Assigned to
nobody
Creator
yshuiv7

Comments

Comment #0 by yshuiv7 — 2015-06-22T07:49:25Z
I tried to instantiation nested template: template a(A) { void a(B)() { } } list this: (a!A)!B Which is parsed as a C-style cast.
Comment #1 by k.hara.pg — 2015-06-22T10:56:39Z
(In reply to Yuxuan Shui from comment #0) > (a!A)!B > > Which is parsed as a C-style cast. It's not a bug. The code is parsed as: (a!A) // a type name a!A with parenthesis ! // unary operator ! B // an identifier B so `(typename) expr` makes a C-style cast. To do what you want, you need to write: alias aA = a!A; aA!B
Comment #2 by yshuiv7 — 2015-06-22T16:52:51Z
(In reply to Kenji Hara from comment #1) > (In reply to Yuxuan Shui from comment #0) > > (a!A)!B > > > > Which is parsed as a C-style cast. > > It's not a bug. The code is parsed as: > > (a!A) // a type name a!A with parenthesis > ! // unary operator ! > B // an identifier B > > so `(typename) expr` makes a C-style cast. > > To do what you want, you need to write: > > alias aA = a!A; > aA!B OK, that makes sense. Butthis(In reply to Kenji Hara from comment #1) > (In reply to Yuxuan Shui from comment #0) > > (a!A)!B > > > > Which is parsed as a C-style cast. > > It's not a bug. The code is parsed as: > > (a!A) // a type name a!A with parenthesis > ! // unary operator ! > B // an identifier B > > so `(typename) expr` makes a C-style cast. > > To do what you want, you need to write: > > alias aA = a!A; > aA!B Well that makes sense. But I still don't think this is the right way. First, (a!A) is not always a type, it can be a function or anything. Second, B is a type, so parse !B as expression is weird. And this makes instantiate nested templates hard.
Comment #3 by k.hara.pg — 2015-06-23T00:19:39Z
(In reply to Yuxuan Shui from comment #2) > First, (a!A) is not always a type, it can be a function or anything. Yes, it's not yet determined in parsing stage. The determination will be done in later semantic analysis stage. > Second, B is a type, so parse !B as expression is weird. Similarly to a!A, B is an identifier expression and it's not yet determined as a type in parsing. A syntactically valid D code may be rejected by semantic analysis, so it's not a problem. Note that, D does not use exclamation mark `!` as binary operator, so !B is always parsed as an unary expression (logical negation). Then prefixing parenthesis (a!A) is parsed as C-style cast. There's no grammar ambiguity.