[swift-evolution] [Pitch] Requiring proactive overrides for default protocol implementations.

[Erica Sadun]

From the Swift Programming Language: Methods on a subclass that override the superclass’s implementation are marked with override—overriding a method by accident, without override, is detected by the compiler as an error. The compiler also detects methods with override that don’t actually override any method in the superclass.

I would like to extend this cautious approach to protocols, forcing the developer to deliberately override an implementation that’s inherited from a protocol extension. This would prevent accidental overrides and force the user to proactively choose to implement a version of a protocol member that already exists in the protocol extension.

I envision this as using the same `override` keyword that’s used in class based inheritance but extend it to protocol inheritance:

protocol A {
    func foo()
}

extension A {
    func foo() { .. default implementation … }
}

type B: A {

    override required func foo () { … overrides implementation … }
}


I’d also like to bring up two related topics, although they probably should at some point move to their own thread if they have any legs:

Related topic 1: How should a consumer handle a situation where two unrelated protocols both require the same member and offer different default implementations. Can they specify which implementation to accept or somehow run both? 

type B: A, C {
    override required func foo() { A.foo(); C.foo() }
}

Related topic 2: How can a consumer “inherit” the behavior of the default implementation (like calling super.foo() in classes) and then extend that behavior further. This is a bit similar to how the initialization chaining works. I’d like to be able to call A.foo() and then add custom follow-on behavior rather than entirely replacing the behavior.

type B: A {
    override required func foo() { A.foo(); … my custom behavior … }
}

cc’ing in Jordan who suggested a new thread on this and Doug, who has already expressed some objections so I want him to  have the opportunity to bring that discussion here.

— E 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160427/231fa1f8/attachment.html>