[Issue 13448] Class specification misses template classes in base classes list
https://issues.dlang.org/show_bug.cgi?id=13448 yebblies yebbl...@gmail.com changed: What|Removed |Added CC||yebbl...@gmail.com --- Comment #7 from yebblies yebbl...@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. --
[Issue 13448] Class specification misses template classes in base classes list
https://issues.dlang.org/show_bug.cgi?id=13448 --- Comment #6 from github-bugzi...@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. --
[Issue 13448] Class specification misses template classes in base classes list
https://issues.dlang.org/show_bug.cgi?id=13448 hst...@quickfur.ath.cx changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 13448] Class specification misses template classes in base classes list
https://issues.dlang.org/show_bug.cgi?id=13448 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added CC||briancsch...@gmail.com --- Comment #5 from Kenji Hara k.hara...@gmail.com --- *** Issue 10234 has been marked as a duplicate of this issue. *** --
[Issue 13448] Class specification misses template classes in base classes list
https://issues.dlang.org/show_bug.cgi?id=13448
--- Comment #4 from Kenji Hara k.hara...@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.
--
[Issue 13448] Class specification misses template classes in base classes list
https://issues.dlang.org/show_bug.cgi?id=13448 --- Comment #3 from hst...@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. --
[Issue 13448] Class specification misses template classes in base classes list
https://issues.dlang.org/show_bug.cgi?id=13448 hst...@quickfur.ath.cx changed: What|Removed |Added Keywords||pull CC||hst...@quickfur.ath.cx --- Comment #1 from hst...@quickfur.ath.cx --- https://github.com/D-Programming-Language/dlang.org/pull/655 --
[Issue 13448] Class specification misses template classes in base classes list
https://issues.dlang.org/show_bug.cgi?id=13448
--- Comment #2 from Kenji Hara k.hara...@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
--
