<div dir="ltr">On Fri, Aug 26, 2016 at 1:53 AM, Charles Srstka <span dir="ltr">&lt;<a href="mailto:cocoadev@charlessoft.com" target="_blank">cocoadev@charlessoft.com</a>&gt;</span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div class="h5"><blockquote type="cite">On Aug 25, 2016, at 11:48 PM, Xiaodi Wu &lt;<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a>&gt; wrote:<br></blockquote><div><blockquote type="cite"><br><div><div dir="ltr" style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div class="gmail_extra"><div class="gmail_quote">On Thu, Aug 25, 2016 at 11:05 PM, Charles Srstka<span> </span><span dir="ltr">&lt;<a href="mailto:cocoadev@charlessoft.com" target="_blank">cocoadev@charlessoft.<wbr>com</a>&gt;</span><span> </span>wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><span><blockquote type="cite">On Aug 25, 2016, at 10:24 PM, Xiaodi Wu &lt;<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a>&gt; wrote:<br></blockquote><div><blockquote type="cite"><br><div><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">Yes, and it&#39;s covered in those previous threads. In brief, not all retroactive modeling involves extending a type:</span><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><br></div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">* A vendor supplies you with a closed-source library with a struct S that conforms to standard library protocol P.</div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><br></div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">* Protocol P requires a method named foo(), so struct S has its own implementation of foo().</div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><br></div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">* You extend protocol P by adding a new default implementation of foo().</div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><br></div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">This cannot be done if a keyword is required for overriding a default implementation. There is also nowhere for you to append any sort of &quot;retro&quot; keyword anywhere, because no part of your own code extends S in any way.</div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><br></div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">Please, please take the time to study the previous threads; we should not be re-playing existing discussions four or five times on this list.</div></div></blockquote></div><br></span><div>How is this a problem, though? The implementation of foo() in S will not break, because it’s already been compiled in. The change will only affect code that is subsequently compiled with your extension of P in place. And it’ll be doing its job; making sure that your code to implement the protocol is there deliberately, and preventing you from accidentally mistyping the method name and thus silently failing to override the default implementation.</div></div></blockquote><div><br></div><div>So you&#39;re saying that the compiler should let you compile your extension of P, even though it knows that the default implementation of `foo()` is not explicitly overridden by S. Fine.</div><div>Now suppose the library is not closed-source; you&#39;re including it in your project and compiling it along with your own code. Are you supposed to fork the library?</div></div></div></div></div></blockquote></div><br></div></div><div>Even if the library is open-source, you&#39;ll presumably be building in as its own target, which will be including only library code and not your extension, and linking it into the application in a later stage of the build process.</div></div></blockquote><div><br></div><div>I made the same argument eight months ago:</div><div><br></div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">&gt;<i> Another option might be to allow imported definitions to be used by a conformance without the `override` marking to support retroactive modeling while requiring definitions in the same module as the conformance to explicitly specify the `override`.<br></i></blockquote><div><br></div><div> But Brent Royal-Gordon had a good point: </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><i>
</i>
But the same problem exists if you want to do this to `internal` types using a `private` protocol. There you *could* make the protocol `internal` and call `override` in all the right places, but if the protocol is an implementation detail of one particular file, why should you?</blockquote></div><div><br></div></div></div></div>