<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">From the Swift Programming Language:&nbsp;<i class="">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 class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">I envision this as using the same `override` keyword that’s used in class based inheritance but extend it to protocol inheritance:</div><div class=""><br class=""></div><div class="">protocol A {</div><div class="">&nbsp; &nbsp; func foo()</div><div class="">}</div><div class=""><br class=""></div><div class="">extension A {</div><div class="">&nbsp; &nbsp; func foo() { .. default implementation … }</div><div class="">}</div><div class=""><br class=""></div><div class="">type B: A {</div><div class=""><br class=""></div><div class="">&nbsp; &nbsp; override required func foo () { … overrides implementation … }</div><div class="">}</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">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?&nbsp;</div><div class=""><br class=""></div><div class="">type B: A, C {</div><div class="">&nbsp; &nbsp; override required func foo() { A.foo(); C.foo() }</div><div class="">}</div><div class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">type B: A {</div><div class="">&nbsp; &nbsp; override required func foo() { A.foo(); … my custom behavior … }</div><div class="">}</div><div class=""><br class=""></div><div class="">cc’ing in Jordan who suggested a new thread on this and Doug, who has already expressed some objections so I want him to &nbsp;have the opportunity to bring that discussion here.</div><div class=""><br class=""></div><div class="">— E&nbsp;</div></body></html>