<div dir="ltr">On Fri, Aug 26, 2016 at 3:55 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><span class=""><blockquote type="cite">On Aug 26, 2016, at 3:39 AM, 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">On Fri, Aug 26, 2016 at 2:30 AM, Charles Srstka<span> </span></span><span 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">&lt;<a href="mailto:cocoadev@charlessoft.com" target="_blank">cocoadev@charlessoft.<wbr>com</a>&gt;</span><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"><span> </span></span><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">wrote:</span><br 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" 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_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><blockquote type="cite">On Aug 26, 2016, at 2:22 AM, 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">On Fri, Aug 26, 2016 at 1:53 AM, Charles Srstka<span> </span><span dir="ltr">&lt;<a href="mailto:cocoadev@charlessoft.com" target="_blank">cocoadev@charlessoft.c<wbr>om</a>&gt;</span><span> </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><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.c<wbr>om</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><span> </span>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></div></div></div></blockquote></div><br></div></div><div>If the protocol is private, than to code outside that file, the protocol effectively doesn’t exist, since code in protocol extensions is statically dispatched (this is also true to code in your hypothetical library). So no need for “override” there.</div></div></blockquote><div><br></div><div>That is incorrect. If it&#39;s a protocol requirement, it&#39;s dynamically dispatched. If I conform an internal type to a private protocol and use that type in the same file where the protocol is defined, that type conforms to the protocol. You would have no way of appending the `override` keyword to the relevant overrides without making the protocol internally visible.</div></div></div></div></blockquote></div><div><br></div></span><div>We were speaking of extending a protocol.</div></div></blockquote><div><br></div><div>That is not exactly what Brent was speaking of. We are talking about this scenario:</div><div><br></div><div>File A:</div><div><br></div><div>```</div><div>internal struct S {</div><div>  func foo() { }</div><div>}</div><div>```</div><div><br></div><div>File B:</div><div><br></div><div>```</div><div>private protocol P {</div><div>  func foo()</div><div>}</div><div><br></div><div>extension P {</div><div>  func foo() { }</div><div>}</div><div><br></div><div>// With your proposal, I can&#39;t write the following line:</div><div>extension S : P { }</div><div>// In file A, S.foo() isn&#39;t overriding anything, so I can&#39;t add `override`</div><div>// But in file B, S can&#39;t conform to P,</div><div>// because S.foo() isn&#39;t overriding P.foo() without `override` in file A</div><div>```</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>This means that either 1) the method we add lives only in the extension, is statically dispatched, and thus does not exist to code that cannot see the extension, or 2) the code that cannot see the extension has been written as if the extension did not exist, and thus must already have another implementation of the method. In neither case does the extension affect the behavior of code that cannot see it.</div><div><br></div><div>If the protocol is private, then your internal type cannot see it. The internal type, which lives in complete blissful ignorance of the private protocol, can coincidentally implement one of the methods, but it is not conforming to the protocol in doing so, and thus does not have any need of adding a keyword to indicate that it is so conforming. If the match in nomenclature is more than coincidental, the intention falls on the private protocol, not the internal type.</div><div><br></div><div>The point of the keyword is to clarify *intentions.* If I am declaring my type as conforming to a protocol, and I am implementing methods that are required by the protocol, I should tell the compiler that the purpose of these methods is to satisfy the protocol. If I am implementing a protocol method that already has a default, I should indicate that I’m doing that on purpose, as well. If I *am not conforming* to the protocol and somebody *else* is adding conformance in an extension, then it’s not my problem and the person doing the conforming should be the one to declare their intent.</div><span class="HOEnZb"><font color="#888888"><br><div>Charles</div><div><br></div></font></span></div></blockquote></div><br></div></div>