[swift-evolution] Replace the override keyword by 'extend' and 'replace' or add an annotation like @SuppressSuperCall

[Jeremy Pereira]

> On 16 Feb 2016, at 17:20, Ilya Belenkiy via swift-evolution <swift-evolution at swift.org> wrote:
> 
> A lot of the time Cocoa documentation says that you must override a method, or must not, and if you do, whether to to it in the beginning, the end, or at some point.

I’m sorry, I don’t believe this. How can the implementor of the superclass possibly know whether the arbitrary code that the implementor of a subclass can write should go before, after or around the call to the super implementation? It’s nonsense.

Furthermore, I don’t believe that the implementor of the super class can foresee all the possible cases of subclass implementation so it would be foolish to try to even enforce a call to super at any point.

Then there are the implementation problems. The attribute would restrict the subclass implementor to calling the super implementation in the implementation of the subclass function. They couldn’t call out to a private method to call the super implementation. They couldn’t put it inside a loop or control structure unless the compiler can definitely prove that the code path is executed.

How do you deal with multi-level hierarchies? Do you enforce adding the attribute to the method in the intermediate class? 

I think the whole idea of the compiler enforcing calls to super for non initialisers is misconceived. There will be enough edge cases and implementation issues to have subclass implementors cursing it. We should just accept the fact that we can’t legislate every bug out of existence and live things as they are.