https://issues.dlang.org/show_bug.cgi?id=13448

hsteoh@quickfur.ath.cx changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |pull
                 CC|                            |hsteoh@quickfur.ath.cx

--- Comment #1 from hsteoh@quickfur.ath.cx ---
https://github.com/D-Programming-Language/dlang.org/pull/655

--

https://issues.dlang.org/show_bug.cgi?id=13448

--- Comment #2 from Kenji Hara <k.hara.pg@gmail.com> ---
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

--

https://issues.dlang.org/show_bug.cgi?id=13448

--- Comment #3 from hsteoh@quickfur.ath.cx ---
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.

--

https://issues.dlang.org/show_bug.cgi?id=13448

--- Comment #4 from Kenji Hara <k.hara.pg@gmail.com> ---
(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.

--

https://issues.dlang.org/show_bug.cgi?id=13448

Kenji Hara <k.hara.pg@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |briancschott@gmail.com

--- Comment #5 from Kenji Hara <k.hara.pg@gmail.com> ---
*** Issue 10234 has been marked as a duplicate of this issue. ***

--

https://issues.dlang.org/show_bug.cgi?id=13448

--- Comment #6 from github-bugzilla@puremagic.com ---
Commit pushed to master at https://github.com/D-Programming-Language/dlang.org

https://github.com/D-Programming-Language/dlang.org/commit/2ab88c406b4b8077d8709f61ea14af43148c9b72 Merge pull request #655 from quickfur/issue13448

Base classes / interfaces may be template instantiations too.

--

https://issues.dlang.org/show_bug.cgi?id=13448

hsteoh@quickfur.ath.cx changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--

https://issues.dlang.org/show_bug.cgi?id=13448

yebblies <yebblies@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |yebblies@gmail.com

--- Comment #7 from yebblies <yebblies@gmail.com> ---
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.

--