<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 12:45 PM, L. Mihalkovic <<a href="mailto:laurent.mihalkovic@gmail.com" class="">laurent.mihalkovic@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">Inline<br class=""><br class=""><div class="">Regards</div>(From<span class="Apple-style-span"> mobile)</span></div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class="">On Apr 27, 2016, at 9:31 PM, Erica Sadun via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div class="">On Apr 27, 2016, at 12:25 PM, Douglas Gregor <<a href="mailto:dgregor@apple.com" class="">dgregor@apple.com</a>> wrote:<br class=""><div class=""><blockquote type="cite" class=""><br class="Apple-interchange-newline"><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">On Apr 27, 2016, at 10:10 AM, Erica Sadun <<a href="mailto:erica@ericasadun.com" class="">erica@ericasadun.com</a>> wrote:<br class=""><div class=""><blockquote type="cite" class=""><br class="Apple-interchange-newline"><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><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 class=""><br class=""></div><div class="">A couple questions about your pitch:</div><div class=""><br class=""></div><div class="">1) What is “required” doing there? </div></div></div></div></blockquote><div class=""><br class=""></div>I threw it in not because I’m tied to it but because I wanted it to be part of the conversation.</div><div class="">This is a requirement from conforming to the protocol.</div><div class=""><br class=""><blockquote type="cite" class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class=""><div class="">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></div></blockquote><div class=""><br class=""></div><div class="">Override is only because it is overriding the default implementation of the protocol requirement. Without that default implementation there would be no override, it would simply be satisfying the requirement.</div><br class=""><blockquote type="cite" class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class=""><div class=""><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></div></blockquote><div class=""><br class=""></div><div class="">Forcing the override keyword makes it clear at the definition point that the story extends beyond the method or whatever to point to a default implementation that is being replaced. I *really* like having that reference in terms of both code construction (“I am doing this as a deliberate act”) with the compiler complaining otherwise, and in terms of code self documentation (“I know this was added deliberately, what default did it override?”)</div><br class=""><blockquote type="cite" class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class=""><div class=""><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></div></div></blockquote><div class=""><br class=""></div>It would be pointless if it’s just satisfying a requirement. That’s why introduced both keywords into the discussion. (And because I’m still being influenced by the “near miss” conversation.)</div><div class=""><br class=""></div></div></blockquote><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class=""></div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">One could always argue that should protocol definitions ever be allowed to contain default implementations ala-java default methods,</div></div></blockquote><div><br class=""></div><div>I fully expect this will happen someday. It would have happened when protocol extensions were introduced except that the implementation was a bit more involved than we had time for.</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""> the distinction between former and latter would go away, and it would be happy anticipation to have mandated *override* all along in all cases, ensuring that future default methods would not accidentally take precedence of current code or wind up being treated differently than other overrides.</div></div></blockquote><div><br class=""></div><div>Please spell out the scenario you are talking about.</div><div><br class=""></div><span class="Apple-tab-span" style="white-space:pre"> </span>- Doug</div><div><br class=""></div></body></html>