<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="" applecontenteditable="true"><br class=""><div><blockquote type="cite" class=""><div class="">On May 16, 2017, at 10:44, Charles Srstka via swift-users <<a href="mailto:swift-users@swift.org" class="">swift-users@swift.org</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=""><blockquote type="cite" class="">On May 16, 2017, at 12:32 PM, Nevin Brackett-Rozinsky via swift-users <<a href="mailto:swift-users@swift.org" class="">swift-users@swift.org</a>> wrote:<br class=""></blockquote><div class=""><blockquote type="cite" class=""><br class="Apple-interchange-newline"><div class=""><span 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; float: none; display: inline !important;" class="">There is not.</span><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="">At some point in the future, I believe the plan is to eventually allow default implementations to be written in-line within the protocol declaration itself. In other words, the fact that default implementations currently must appear in extensions, is a temporary limitation that has not yet been a priority to address.</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="">Once we gain the ability to define default implementations within protocols themselves, rather than extensions, then your use-case will “just work” (at least as long as you control the protocol anyway). I wouldn’t hold my breath though, as that behavior will not appear this year, and the plans for next year have not been hashed out yet.</div></div></blockquote></div><br class=""><div class="">Even that won’t completely solve the problem, though, because:</div><div class=""><br class=""></div><div class="">protocol P {</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>func foo() {</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>// default implementation</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>}</div><div class="">}</div><div class=""><br class=""></div><div class="">struct S: P {</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>func foo() {</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>// overriden implementation</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>}</div><div class="">}</div><div class=""><br class=""></div><div class="">If foo is refactored here, S will start getting the wrong implementation of it, silently, with no warning.</div><div class=""><br class=""></div><div class="">People have tried to bring up proposals to add some sort of “override”-like keyword for protocols on swift-evolution a bunch of times, but it always gets shouted down by certain members of the group, so we’re probably permanently stuck with this situation where a supposedly “protocol-oriented” language is not safe to use with protocols.</div></div></div></blockquote><br class=""></div><div>I object to this characterization. People have tried to bring up such proposals, and it is invariably pointed out (usually by the same group of us) that these proposals don't discuss retroactive modeling, and then the thread dies. I can't remember a case where the proposal author actually incorporates this feedback into their proposal to handle retroactive modeling, or extension members of one protocol being used as the default implementation of another protocol.</div><div><br class=""></div><div>(This just means the problem space is more difficult than the proposer initially thought, and they're not going to take that on right now, which is fine. It's a learning experience; designing features that interact well with the whole language is not easy! We should probably add this to the "commonly proposed" list, though, so that we don't keep retreading that initial ground.)</div><div><br class=""></div><div>Jordan</div><br class=""></body></html>