<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class="">[Proposal: <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0164-remove-final-support-in-protocol-extensions.md" class="">https://github.com/apple/swift-evolution/blob/master/proposals/0164-remove-final-support-in-protocol-extensions.md</a>]</div><br class=""><div><blockquote type="cite" class=""><div class="">On Apr 5, 2017, at 16:15, Howard Lovatt via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</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; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="background-color: rgba(255, 255, 255, 0);" class="">The review of SE-0164 "Remove final support in protocol extensions"</span></div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; 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; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><blockquote type="cite" class=""><ul class="" style="box-sizing: border-box; padding-left: 2em; margin-top: 0px; margin-bottom: 16px;"><li class="" style="box-sizing: border-box;"><font class=""><span style="background-color: rgba(255, 255, 255, 0);" class="">What is your evaluation of the proposal?</span></font></li></ul></blockquote><div class="">The present situation isn't great. People get confused about which method will called with protocol extensions. Seems like every week there is a variation on this confusion on Swift Users mailing list. Therefore something needs to be done. </div><div class=""><br class=""></div><div class="">However I am not keen on this proposal since it makes behaviour inconsistent between methods in protocol extensions, classes, and structs. </div><div class=""><br class=""></div><div class="">I think a better solution would be one of the following alternatives:</div><div class=""><br class=""></div><div class=""> 1. Must use final and final means it cannot be overridden; or</div><div class=""> 2. If not final dispatches using a table like a class and if marked final cannot be overridden and if marked dynamic uses obj-c dispatching; or</div><div class=""> 3. Must be marked dynamic and uses obj-c dispatching. </div><div class=""><br class=""></div><div class="">My preference would be option 2 but I think any of the three is superior to the present situation or the proposal. </div></div></div></blockquote><div><br class=""></div><div>People have suggested all of these before, but none of them are obviously correct. It's true that we have a difference between extension members that satisfy requirements and those that don't, and that that confuses people. However, an extension-only member of one protocol can be used to satisfy the requirements of another protocol today, which is a tool for code reuse.</div><div><br class=""></div><div>(I <i class="">think</i> we managed to convince everyone that it's just a bug that a protocol extension method that satisfies a requirement cannot be overridden in a subclass, so at least that isn't an issue on top of the rest of this.)</div><div><br class=""></div><div>Oh, and we can't retroactively add members of a protocol extension to existing adopters, which is why protocol extension members cannot be @objc. There are limited circumstances where that would be safe, but that would be a separate proposal.</div><div><br class=""></div><div>Jordan</div></div></body></html>