<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Apr 28, 2016 at 9:53 PM, Erica Sadun <span dir="ltr">&lt;<a href="mailto:erica@ericasadun.com" target="_blank">erica@ericasadun.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><span class=""><br><div><blockquote type="cite"><div>On Apr 28, 2016, at 8:46 PM, Xiaodi Wu &lt;<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a>&gt; wrote:</div><div><div dir="ltr"><div class="gmail_extra">Let&#39;s return to the toy example. Suppose I license the following code from a third party. I am allowed to incorporate it unmodified into my project:</div><div class="gmail_extra"><br></div><div class="gmail_extra"><div style="font-size:12.8px">```</div><div style="font-size:12.8px">// I cannot touch any of the following code</div><div style="font-size:12.8px"><div>struct A {</div><div>    func frobnicate() { print(&quot;A&quot;) }</div><div>}</div><div>struct B {</div><div>    func frobnicate() { print(&quot;B&quot;) }</div><div>}</div><div>struct C { }</div></div><div style="font-size:12.8px">```</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">The code above has three types that conform to no protocols. Nothing would change on adoption of your proposal. As licensed to me from the third party, there are no protocols for it to conform to.</div><div style="font-size:12.8px"><span style="font-size:12.8px"><br></span></div><div style="font-size:12.8px"><span style="font-size:12.8px">Now, in a separate file, as part of my own code, I want to conform these three types to a protocol of my own design, Frobnicatable, and supply a default `frobnicate()`:</span></div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">```</div><div style="font-size:12.8px"><div>protocol Frobnicatable {</div><div>    func frobnicate()</div><div>}</div><div>extension Frobnicatable {</div><div>    func frobnicate() { print(&quot;Default&quot;) }</div><div>}</div><div>extension A: Frobnicatable { }</div><div>extension B: Frobnicatable { }</div><div>extension C: Frobnicatable { }</div></div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">let a = A()</div><div style="font-size:12.8px">a.frobnicate() // &quot;A&quot;</div><div style="font-size:12.8px">let c = C()</div><div style="font-size:12.8px">c.frobnicate() // &quot;Default&quot;</div><div style="font-size:12.8px">```</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">It seems like there is nothing I can do to make this work upon implementation of your proposal.</div></div></div>
</div></blockquote></div><br></span><div>Is this your desired behavior or is this the behavior you expect?</div><div>By implementing a default, you inherit that behavior in all three, because *you* added it.</div><div><div>I expect the compiler to complain at your default because you did not mark it as required.</div></div><div><br></div><div>If you want to use the inherent frobnicate and not the default one that you just added,</div><div>you will need to do something like:</div><div><br></div><div>extension A: Frobnicate {</div><div>   override required frobnicate = A.frobnicate</div><div>}</div></div></blockquote><div> </div><div>What&#39;s shown in comments is how it *currently* behaves. That can be verified in a playground (or the IBM sandbox online). I&#39;m not sure I have a strong opinion yet on how it *should* behave, although what I&#39;m asking is whether I *can* make it behave in the same way as it does currently.</div><div><br></div><div>If what you show above as a solution is part of your proposal, then that should be sufficient to support my use case. Please do document it in the text though. IMO, this is key. It&#39;s not enough to say, just modify the original code, or just use a compiled module, or hope that the code is written in something other than Swift 3.</div><div><br></div><div>I still have reservations about requiring both `override` and `required`, which current Swift syntax never does. I understand what you&#39;re getting at, but I&#39;m not sure making the distinction between `override` and `override required` will provide additional safety in practice. My reasoning: `override` implies that there&#39;s an implementation provided somewhere, and `required` implies there&#39;s a protocol requirement somewhere, but either one alone is sufficient to tell the compiler &quot;yes, I intend to write a function with the same name as something else--please tell me if I failed to do so.&quot; What would be lost (safety-wise) if we followed Swift precedent, and `override required` got simplified to `override`?</div><div><br></div><div><br></div></div></div></div>