Thread overview | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|
|
September 18, 2014 [Issue 13448] Class specification misses template classes in base classes list | ||||
---|---|---|---|---|
| ||||
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 -- |
September 19, 2014 [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.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 -- |
September 19, 2014 [Issue 13448] Class specification misses template classes in base classes list | ||||
---|---|---|---|---|
| ||||
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. -- |
September 21, 2014 [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.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. -- |
September 22, 2014 [Issue 13448] Class specification misses template classes in base classes list | ||||
---|---|---|---|---|
| ||||
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. *** -- |
October 02, 2014 [Issue 13448] Class specification misses template classes in base classes list | ||||
---|---|---|---|---|
| ||||
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. -- |
October 02, 2014 [Issue 13448] Class specification misses template classes in base classes list | ||||
---|---|---|---|---|
| ||||
https://issues.dlang.org/show_bug.cgi?id=13448 hsteoh@quickfur.ath.cx changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED -- |
November 11, 2014 [Issue 13448] Class specification misses template classes in base classes list | ||||
---|---|---|---|---|
| ||||
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. -- |
Copyright © 1999-2021 by the D Language Foundation