Bug 2525 – Can't use `override` when implementing abstract base class's interface function

interface I { void foo(); } abstract class A : I { } class B : A { override void foo () {} } The above code fails to compile: overrideBaseInterface.d(10): function overrideBaseInterface.B.foo does not override any function It looks to me like B.foo is overriding I.foo and hence the override keyword should be valid.

DMD Git head: https://github.com/D-Programming-Language/dmd/commit/13b3bdbf3819fec810ebfb077957510612dfa815 -------------------- test.d(10): Error: function test.B.foo does not override any function, did you mean to override 'test.I.foo'? -------------------- Yes, I did!

Technically you're not overriding, you're implementing. I think there is no bug here. I also think the following should be an error: ----- interface I { void foo(); } class C : I { override void foo () {} // no error here currently } ----

I think `override` keyword is useful to mark the methods that are supposed to be declared elsewhere. In the following example I'm also (technically) implementing: -------------------- abstract class A { void foo(); } class B : A { void foo () {} } -------------------- test.d(7): Deprecation: overriding base class function without using override attribute is deprecated (test.B.foo overrides test.A.foo) --------------------

(In reply to comment #2) > Technically you're not overriding, you're implementing. I think there is no bug > here. I also think the following should be an error: > > ----- > interface I > { > void foo(); > } > > class C : I > { > override void foo () {} // no error here currently > } > ---- Voting up this bug report. Semantical difference between overriding and implementing is very subtle here. One can also say that it overrides function with empty implementation. However, what does matter here is pragmatical usability it brings to the table. http://dlang.org/attribute.html#override > The override attribute applies to virtual functions. It means that the > function must override a function with the same name and parameters in a base > class. The override attribute is useful for catching errors when a base > class's member function gets its parameters changed, and all derived classes > need to have their overriding functions updated. This description does miss one important use case - verifying that you do not introduce a new function symbol in the class hierarchy. Consider this example: in the process of wild refactoring interface signature changes and dependent classes get modified. A sloppy programmer works on new implementation of that functions and forgets that there is already existing one. However, code compiles and works, polluting sources with unused function body.

(In reply to comment #4) > A sloppy programmer works on new implementation of that > functions and forgets that there is already existing one. However, code > compiles and works, polluting sources with unused function body. I agree 'override' adds to the readability, however D already protects you against function hiding and function hijacking. For example: ----- class A { void foo() { } } class B : A { void foo() { } } ----- test.d(10): Deprecation: overriding base class function without using override attribute is deprecated (test.B.foo overrides test.A.foo) I don't know why I wrote http://d.puremagic.com/issues/show_bug.cgi?id=2525#c2, I do believe override makes the code more readable. Ideally we would have an "implements" keyword, but you know, keyboard bloat and all that.

*** Issue 10699 has been marked as a duplicate of this issue. ***

*** Issue 12329 has been marked as a duplicate of this issue. ***

Shame on you, Andrej Mitrovic! I totally support this now, perhaps not so much 'override' as wanting a new 'implements' keyword. But the distinction is so pale, and the real benefit is really *knowing* that a method is actually part of a base class / interface API, so I'm now definitely in huge favor of allowing (and perhaps even *requiring*) override for implementing keywords.

I just hit this bug too and I wasn't so fortunate as to realise that classes that implement an interface need override but classes that extend and abstract class which implements an interface must not have the "override" attribute. Please make it consistent!

Just ran into this, so I'll bump it. Note that if, in the OP's code, you change the abstract class A to an empty interface, the code successfully compiles.

*** Issue 16318 has been marked as a duplicate of this issue. ***

Any news on this? People periodically hits this issue and finds it very strange...

See Issue 9978 for why we allow to override interface functions. The given code should work.

As a workaround one can redeclare the interface methods in the abstract class. ---- interface I { void foo(); } abstract class A : I { override void foo(); } class B : A { override void foo () {} } ---- Note that this bug and the workaround also applies to implicit abstract classes. ---- interface I { void foo(); } class A : I { abstract override void foo(); } class B : A { override void foo () {} } ----

@seeseemelk created dlang/dmd pull request #12232 "Fix 2525: check all parent interfaces for overriden methods" fixing this issue: - Fix 2525: check all parent interfaces for overriden methods https://github.com/dlang/dmd/pull/12232

@ntrel created dlang/dmd pull request #14853 "Fix 2525: check all parent interfaces for overriden methods" fixing this issue: - Fix 2525: check all parent interfaces for overriden methods Fix 2525: refactor in order to use Array!(BaseClass) instead of dynamic array and show deprecation Fix 2525: test if function is implemented by a parent class before throwing an error Fix 2525: make forAllInterfaces take a delegate issue 2525: add unit tests issue 2525: update documentation https://github.com/dlang/dmd/pull/14853

THIS ISSUE HAS BEEN MOVED TO GITHUB https://github.com/dlang/dmd/issues/17816 DO NOT COMMENT HERE ANYMORE, NOBODY WILL SEE IT, THIS ISSUE HAS BEEN MOVED TO GITHUB