<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=""><br class=""><div><blockquote type="cite" class=""><div class="">On Apr 27, 2016, at 10:10 AM, Erica Sadun <<a href="mailto:erica@ericasadun.com" class="">erica@ericasadun.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">From the Swift Programming Language: <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=""> func foo()</div><div class="">}</div><div class=""><br class=""></div><div class="">extension A {</div><div class=""> 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=""> override required func foo () { … overrides implementation … }</div><div class="">}</div></div></div></blockquote><div><br class=""></div><div>A couple questions about your pitch:</div><div><br class=""></div><div>1) What is “required” doing there? </div><div><br class=""></div><div>2) Is “override” only required when there is a default implementation of the protocol requirement, or is it required whenever you are implementing a protocol requirement?</div><div><br class=""></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>* If the former, it might be the case that it’s too easy to forget to add the “override” keyword (because it’s needed for some implementations of protocol requirements but not others), which undercuts the value of having it.</div><div><br class=""></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>* If the latter, “override” is probably the wrong keyword because it’s not overriding anything in the common case of implementing a non-defaulted requirement.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><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? </div><div class=""><br class=""></div><div class="">type B: A, C {</div><div class=""> override required func foo() { A.foo(); C.foo() }</div><div class="">}</div></div></div></blockquote><div><br class=""></div><div>I think the right answer here is for the compiler to produce an ambiguity if you don’t implement the requirement yourself, and then solving your “related topic 2” lets you choose which implementation you want.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><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=""> override required func foo() { A.foo(); … my custom behavior … }</div><div class="">}</div></div></div></blockquote><div><br class=""></div><div>Seems totally reasonable to me. One ugly syntax: A.foo(self)(), leveraging the currying of self?</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><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 have the opportunity to bring that discussion here.</div></div></div></blockquote><br class=""></div><div>My objections are described here:</div><div><br class=""></div><div><span class="Apple-tab-span" style="white-space:pre"> </span><a href="http://thread.gmane.org/gmane.comp.lang.swift.devel/1799/focus=1831" class="">http://thread.gmane.org/gmane.comp.lang.swift.devel/1799/focus=1831</a></div><div><br class=""></div><div>Essentially, my argument is that the point of “override” (as pitched above) is to declare the user’s intent to implement a requirement. I feel that the explicit protocol conformance ("type B : A”) declares that intent, and that various common conventions (e.g., one conformance per extension, where the extension is primarily there to conform to the protocol) reinforce intent well enough for the compiler to do a good job here. I’d prefer that over another boilerplate-y keyword.</div><div><br class=""></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>- Doug</div><div><br class=""></div><br class=""></body></html>