https://issues.dlang.org/show_bug.cgi?id=13448
--- Comment #4 from Kenji Hara <[email protected]> --- (In reply to hsteoh from comment #3) > I'm not sure about basing the spec on the quirks of the current > implementation. Conceptually speaking, the base class list consists of zero > or one base classes, followed by zero or more interfaces. Just because the > implementation currently parses it as BasicType doesn't mean that that's the > way the spec should be written. Grammar definition cannot define all D semantic specification. > What does it mean, for example, to write > "class C : int, string, float", which would be valid according to the > BasicType definition? Obviously, the *intention* is that only valid base > classes / interfaces (including any respective template instantiations) are > included in the list, even if the compiler currently implements this as a > list of BasicTypes and a post-parsing type check. I think the spec would be > much clearer if written according to intention rather than the quirks of the > current implementation. The post-parsing type check cannot be avoidable even when the "much cleaner grammar" is defined. See: class C : int {} // The semantic error can be detected in parsing phase alias B = int; class C : B {} // The semantic error cannot be detected in parsing phase Of course, we can reject the syntax `class C : int {}` in parsing by the more strict grammar definition. But it will increase grammar complexity and will make more difficult to implement D parser. Therefore, it's is reasonable that using `BasicType` in the `SuperClass` and `Interfaces` definition to simplify grammar definition. --
