On Tue, 30 Aug 2011 08:26:17 -0400, Andrei Alexandrescu
<seewebsiteforem...@erdani.org> wrote:
On 08/30/2011 07:13 AM, Timon Gehr wrote:
If there already is an implementation, it overrides it, otherwise it
implements it.
That's pretty much it. The entire purpose of the "override" keyword is
to prevent silent bugs of two kinds:
(a) User thinks she hooks a specific method but instead introduces a new
one.
(b) User thinks she introduces a new method but instead hooks one.
Override helps only in cases where otherwise a silent error would occur.
If the compiler issues an error message without the help of override,
override is unneeded and illegal. This is the case with interface and
abstract methods - "override" is emphatically unneeded because the
compiler/linker wouldn't allow the code anyway.
Your (a) and (b) points seem to be pointing to a different conclusion --
that override should be required for interface methods. Since
implementing an interface method does not introduce a new method, it hooks
the interface's existing one.
I personally think override should be required if it overrides an existing
implementation, be rejected if it introduces a completely new symbol, and
be optional if it implements an abstract method. The latter rule is
purely for code maintenance. 99%, no wait, I think 100% of the time, when
a previously abstract base method grows an implementation after you have
implemented it in a derived method, the remedy is simply adding override.
This feels like annoyance that can be avoided by just putting override on
it to begin with. I can't think of a single case where I've implemented a
function I *know* is callable by some base class symbol that I'd want to
be informed when a base class implements it later on. I don't care, I'm
overriding it, no matter what the base class does (unless of course, the
base class marks it final, but that would be an error anyways).
If the rule must be require or reject, I'd prefer requirement, even for
interface methods.
-Steve
