<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Aug 26, 2016 at 3:43 PM, Charles Srstka <span dir="ltr">&lt;<a href="mailto:cocoadev@charlessoft.com" target="_blank">cocoadev@charlessoft.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><br></div><div><span class=""><div>On Aug 26, 2016, at 3:19 PM, Xiaodi Wu &lt;<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a>&gt; wrote:</div><br></span><div><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><span><div><blockquote type="cite"><div><div></div></div></blockquote></div></span></div></blockquote><blockquote type="cite"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><span><div><blockquote type="cite"><div><div>Why? S.foo() is visible throughout the module, but outside this file, S.foo() doesn&#39;t override anything. Why should it be marked as an `override` when, as you say, the generated interface shows no sign of conformance to P?</div><div>In addition, how would you justify a requirement to fiddle with these keywords when someone simply refactors an internally visible type with no private members from one file to another? Your proposed rule just broke copy-and-paste...</div></div></blockquote></div><div><br></div></span><div>Because it indicates the programmer’s *intent.* If the protocol is visible at the time you’re writing the declaration for S.foo(), then you should have to tell the compiler what you mean by that and what you’re doing with it.</div></div></blockquote><div><br></div><div>Where a type is located in relation to a protocol is a poor proxy for whether one was written _before_ the other. And while the writer&#39;s most likely intent might differ depending on the order in which two things are written, how one declares members on a type should not be determined by a set of arbitrary rules for the compiler to guess whether the type or protocol was written first. This kind of functionality, if you want it, might be appropriate for a linter. It could probably even look at last modified dates, or with a git repo, go line by line to see when each piece of the code was written.</div></blockquote><div><br></div></span><div>Why should it matter when the programmer wrote it?</div></div></div></div></div></div></div></div></blockquote><div><br></div><div>I don&#39;t know--that&#39;s your suggestion, not mine: &quot;If the protocol is visible at the time you’re writing the declaration for S.foo(), then you should have to tell the compiler what you mean by that...&quot;</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><div><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>One is the declaration, the other is an add-on to it. Conceptually, the type is constructed first, and then things are bolted on (and in Objective-C, that’s literally what  happened; I don’t know how it is implemented in Swift, but conceptually this is how the mental model works).</div><div><br></div><div>Should I not have to add an “override” keyword to a subclass method simply because I wrote that method first and only refactored it into a superclass method after the fact?</div><div><br></div><div>This seems like a fairly silly objection, IMO.</div></div></div></div></div></div></div><span class=""><div><blockquote type="cite"><div></div></blockquote></div></span></div></blockquote><div>I agree, it seems silly. Can you explain what you meant?<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><span class=""><div><blockquote type="cite"><div>On Aug 26, 2016, at 3:23 PM, Xiaodi Wu &lt;<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a>&gt; wrote:</div><br><div><blockquote class="gmail_quote" 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;margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div>If you want it all to compile at the same time, well, we’ve still got access to all the Objective-C runtime functions in Swift. One can also write the assembly by hand. Things like “override” aren’t security features; they’re there to help you do the right thing. If you’re deliberately trying to do the wrong thing, I don’t think that can strictly be prevented.</div></div></blockquote><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">The current syntax is not the &quot;wrong thing&quot;--and a future language feature shouldn&#39;t leave a loophole where someone can choose either one or another totally different set of rules for conforming a type to a protocol; there should be one syntax for doing that in Swift.</div></div></blockquote></div><br></span><div>The current syntax allows many opportunities to do the wrong thing.</div><div><br></div><div>This is the wrong thing:</div><div><br></div><div>protocol P {</div><div><span style="white-space:pre-wrap">        </span>func foo(bar: Baz)</div><div>}</div><div><br></div><div>extension P {</div><div><span style="white-space:pre-wrap">        </span>func foo(bar: Baz) {}</div><div>}</div><div><br></div><div>struct S: P {</div><div><span style="white-space:pre-wrap">        </span>func foo(baz: Baz) {}</div><div>}</div><div><br></div><div>Refactoring this can result in another wrong thing:</div><div><br></div><div>protocol P {</div><div><span style="white-space:pre-wrap">        </span>func foo(bar: Baz, qux: Quux)</div><div>}</div><div><br></div><div>extension P {</div><div><span style="white-space:pre-wrap">        </span>func foo(bar: Baz) {}</div><div>}</div><div><br></div><div>etc. etc. etc.</div><div><br></div><div>Currently it’s hard for a linter to catch things like this, because there’s no way to know that I *didn’t* mean to define a similarly, but not exactly, named function, just as there’s no way to know that I *didn’t* mean to provide a simplified version of the function in the extension. And etc. If I could tell the compiler what I mean by those declarations, suddenly they it becomes possible to check them for accuracy.</div></div></blockquote><div><br></div><div>Or, instead, you could tell a linter these things if you choose; I&#39;m saying your proposal of having distinct before-the-fact and after-the-fact syntax for protocol conformance doesn&#39;t make for a good language feature, IMO.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><span class=""><font color="#888888"><div><br></div><div>Charles</div><div><br></div></font></span></div></blockquote></div><br></div></div>