Thread overview | ||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
June 30, 2009 [Issue 3113] New: final overriding | ||||
---|---|---|---|---|
| ||||
http://d.puremagic.com/issues/show_bug.cgi?id=3113 Summary: final overriding Product: D Version: 2.030 Platform: x86 OS/Version: Windows Status: NEW Severity: normal Priority: P2 Component: DMD AssignedTo: nobody@puremagic.com ReportedBy: tim.matthews7@gmail.com This code compiles: module test; enum A { a = 0 } enum B { b = 1 } class BaseClass { final A getEnum() { return A.a; } } class DerivedClass : BaseClass { B getEnum() { return B.b; } } void main() { auto der = new DerivedClass(); der.getEnum(); } -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- |
June 16, 2011 [Issue 3113] final overriding | ||||
---|---|---|---|---|
| ||||
Posted in reply to tim.matthews7@gmail.com | http://d.puremagic.com/issues/show_bug.cgi?id=3113 yebblies <yebblies@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |yebblies@gmail.com Resolution| |INVALID --- Comment #1 from yebblies <yebblies@gmail.com> 2011-06-16 04:23:17 PDT --- B getEnum() is not overriding final A getEnum() It's simply creating a new function. Yet another reason the override attribute should be compulsory. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- |
June 16, 2011 [Issue 3113] final overriding | ||||
---|---|---|---|---|
| ||||
Posted in reply to tim.matthews7@gmail.com | http://d.puremagic.com/issues/show_bug.cgi?id=3113 klickverbot <code@klickverbot.at> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED CC| |code@klickverbot.at Resolution|INVALID | --- Comment #2 from klickverbot <code@klickverbot.at> 2011-06-16 05:11:37 PDT --- Reopening this, as the compiler doesn't even error out with the »-w« switch – the »override compulsory« check seems to be broken in the presence of »final«. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- |
June 16, 2011 [Issue 3113] final overriding | ||||
---|---|---|---|---|
| ||||
Posted in reply to tim.matthews7@gmail.com | http://d.puremagic.com/issues/show_bug.cgi?id=3113 --- Comment #3 from yebblies <yebblies@gmail.com> 2011-06-16 05:18:11 PDT --- (In reply to comment #2) > Reopening this, as the compiler doesn't even error out with the »-w« switch – the »override compulsory« check seems to be broken in the presence of »final«. Where should the override attribute be required? There is no overriding happening anywhere in the example. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- |
June 16, 2011 [Issue 3113] final overriding | ||||
---|---|---|---|---|
| ||||
Posted in reply to tim.matthews7@gmail.com | http://d.puremagic.com/issues/show_bug.cgi?id=3113 --- Comment #4 from klickverbot <code@klickverbot.at> 2011-06-16 05:23:12 PDT --- R(In reply to comment #3) > (In reply to comment #2) > > Reopening this, as the compiler doesn't even error out with the »-w« switch – the »override compulsory« check seems to be broken in the presence of »final«. > > Where should the override attribute be required? There is no overriding happening anywhere in the example. Remove the »final« attribute and compile the example with -w, and you'll see. Besides, since when would it be allowed to have two public methods with the same signature? --- Comment #5 from klickverbot <code@klickverbot.at> 2011-06-16 05:23:13 PDT --- R(In reply to comment #3) > (In reply to comment #2) > > Reopening this, as the compiler doesn't even error out with the »-w« switch – the »override compulsory« check seems to be broken in the presence of »final«. > > Where should the override attribute be required? There is no overriding happening anywhere in the example. Remove the »final« attribute and compile the example with -w, and you'll see. Besides, since when would it be allowed to have two public methods with the same signature? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- |
June 16, 2011 [Issue 3113] final overriding | ||||
---|---|---|---|---|
| ||||
Posted in reply to tim.matthews7@gmail.com | http://d.puremagic.com/issues/show_bug.cgi?id=3113 --- Comment #4 from klickverbot <code@klickverbot.at> 2011-06-16 05:23:12 PDT --- R(In reply to comment #3) > (In reply to comment #2) > > Reopening this, as the compiler doesn't even error out with the »-w« switch – the »override compulsory« check seems to be broken in the presence of »final«. > > Where should the override attribute be required? There is no overriding happening anywhere in the example. Remove the »final« attribute and compile the example with -w, and you'll see. Besides, since when would it be allowed to have two public methods with the same signature? --- Comment #5 from klickverbot <code@klickverbot.at> 2011-06-16 05:23:13 PDT --- R(In reply to comment #3) > (In reply to comment #2) > > Reopening this, as the compiler doesn't even error out with the »-w« switch – the »override compulsory« check seems to be broken in the presence of »final«. > > Where should the override attribute be required? There is no overriding happening anywhere in the example. Remove the »final« attribute and compile the example with -w, and you'll see. Besides, since when would it be allowed to have two public methods with the same signature? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- |
June 16, 2011 [Issue 3113] final overriding | ||||
---|---|---|---|---|
| ||||
Posted in reply to tim.matthews7@gmail.com | http://d.puremagic.com/issues/show_bug.cgi?id=3113 bearophile_hugs@eml.cc changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bearophile_hugs@eml.cc --- Comment #6 from bearophile_hugs@eml.cc 2011-06-16 05:25:54 PDT --- Even if D is working according to specs, I think this is bug-prone enough to deserve some warning or even an error. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- |
June 16, 2011 [Issue 3113] final overriding | ||||
---|---|---|---|---|
| ||||
Posted in reply to tim.matthews7@gmail.com | http://d.puremagic.com/issues/show_bug.cgi?id=3113 --- Comment #7 from yebblies <yebblies@gmail.com> 2011-06-16 06:48:41 PDT --- (In reply to comment #5) > > Remove the »final« attribute and compile the example with -w, and you'll see. > I get an error when compiling without the final attribute, -w or not. testx.d(21): Error: function testx.DerivedClass.getEnum of type B() overrides but is not covariant with testx.BaseClass.getEnum of type A() > Besides, since when would it be allowed to have two public methods with the same signature? Yes, overloading on return type is disabled for functions in the same scope, but the rules are a little less strict for deriving classes... Looking at the spec, it seems to be explicitly disallowed for functions that would otherwise be virtual. It can be very useful with template functions, as they need to be redefined in each class, and is allowed for static functions. I might be misunderstanding, please post a test case that shows what you mean. (In reply to comment #6) > Even if D is working according to specs, I think this is bug-prone enough to deserve some warning or even an error. I think it would be much clearer if override was mandatory, and I'm fairly sure there's already a report for that. If there's something else you'd like, please, write it up. A test case that compiles does not constitute an enhancement request without additional information. (unless it's very, very obvious) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- |
June 16, 2011 [Issue 3113] final overriding | ||||
---|---|---|---|---|
| ||||
Posted in reply to tim.matthews7@gmail.com | http://d.puremagic.com/issues/show_bug.cgi?id=3113 Steven Schveighoffer <schveiguy@yahoo.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |schveiguy@yahoo.com --- Comment #8 from Steven Schveighoffer <schveiguy@yahoo.com> 2011-06-16 07:54:25 PDT --- I think it is a bug. If the case was that a final function could be masked by a derived class, then this should compile: module test; enum A { a = 0, b = 1 } class BaseClass { final A getEnum() { return A.a; } } class DerivedClass : BaseClass { A getEnum() { return A.b; } } But I get the error: bug3113.d(19): Error: function test.DerivedClass.getEnum cannot override final function test.BaseClass.getEnum This occurs even when I mark DerivedClass' function as final. I was about to mark this as invalid, citing this as a better example, but since the compiler complains about masking in this case, I don't see why the original case is allowed. I believe this kind of thing is allowed in C++. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- |
June 16, 2011 [Issue 3113] final overriding | ||||
---|---|---|---|---|
| ||||
Posted in reply to tim.matthews7@gmail.com | http://d.puremagic.com/issues/show_bug.cgi?id=3113 --- Comment #9 from klickverbot <code@klickverbot.at> 2011-06-16 08:06:26 PDT --- (In reply to comment #8) > This occurs even when I mark DerivedClass' function as final. I think it is quite clear that the example you gave shouldn't compile, as the spec has: »Functions marked as final may not be overridden in a derived class, unless they are also private.« The question now is whether the same behavior should also apply to the example from above. I'm strongly in favor of that, because otherwise, there can be situation where the following two pieces of code don't refer to the same »bar()«, which is completely contrary to how classes usually work in D: --- auto foo = new Derived(); foo.bar(); --- --- Base foo = new Derived(); foo.bar(); --- -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- |
Copyright © 1999-2021 by the D Language Foundation