+1<div><br></div><div>Main part of proposal: Not sure that you need the required keyword, overload alone has proven sufficient in Java for the same feature.<div><br></div><div>Related features: For calling default implementations in inherited protocols I think this is a valuable feature but should be a seperate thread.<br><br>On Thursday, 28 April 2016, Erica Sadun via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>&gt; wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>From the Swift Programming Language: <i>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></div><div><br></div><div>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.</div><div><br></div><div>I envision this as using the same `override` keyword that’s used in class based inheritance but extend it to protocol inheritance:</div><div><br></div><div>protocol A {</div><div>    func foo()</div><div>}</div><div><br></div><div>extension A {</div><div>    func foo() { .. default implementation … }</div><div>}</div><div><br></div><div>type B: A {</div><div><br></div><div>    override required func foo () { … overrides implementation … }</div><div>}</div><div><br></div><div><br></div><div>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:</div><div><br></div><div>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? </div><div><br></div><div>type B: A, C {</div><div>    override required func foo() { A.foo(); C.foo() }</div><div>}</div><div><br></div><div>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.</div><div><br></div><div>type B: A {</div><div>    override required func foo() { A.foo(); … my custom behavior … }</div><div>}</div><div><br></div><div>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.</div><div><br></div><div>— E </div></div></blockquote></div></div><br><br>-- <br>-- Howard.<br>