(http://dlang.org/class.html#ClassDeclaration) says after ':' there is a list of base classes. But "BaseClassList" rule allows only 'Identifier' separated with comma. 'TemplateInstance' rule must be added.
Let's open sample code from http://dlang.org/template.html
> interface Addable(T)
> {
> final R add(this R)(T t)
> {
> return cast(R)this; // cast is necessary, but safe
> }
> }
>
> class List(T) : Addable!T
> {
> List remove(T t)
> {
> return this;
> }
> }
>
> void main()
> {
> auto list = new List!int;
> list.add(1).remove(1); // ok
> }
I want to pay attention at line 9:
> class List(T) : Addable!T
"Addable!T" doesn't fit rule 'BaseClassList'.
This sample code is compiled by DMD2 compiler (but interface must be replaced with class previously). So I think specification must be updated in "SuperClass" and "Interface" rules.
> SuperClass:
> Identifier
> TemplateInstance
>
> Interface:
> Identifier
> TemplateInstance
Other accepted cases:
class B { static class B1 { static class B2 {} } }
class X(T) { static class X1 { static class X2(U) {} } }
class C1 : .B {}
class C2 : B.B1.B2 {}
class C3 : typeof(new B()) {}
class C4 : X!int.X1.X2!string {}
Current dmd parser uses parseBasicType() for base classes.
https://github.com/D-Programming-Language/dmd/blob/master/src/parse.c#L2181
So the `SuperClass` and `Interface` should be aliased names of BasicType.
http://dlang.org/declaration#BasicType
Comment #3 by hsteoh — 2014-09-19T06:05:23Z
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. 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.
Comment #4 by k.hara.pg — 2014-09-21T04:31:30Z
(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.
Comment #5 by k.hara.pg — 2014-09-22T01:46:55Z
*** Issue 10234 has been marked as a duplicate of this issue. ***
Comment #6 by github-bugzilla — 2014-10-02T21:47:54Z
FWIW, what Kenji said was exactly the reasoning behind using parseBasicType to parse base class types. And the grammar must reflect this, otherwise a parser implemented from the spec will differ from dmd in what is accepted inside a version(none) block.