<div dir="ltr">On Sun, May 22, 2016 at 3:38 PM, Brent Royal-Gordon via swift-evolution <span dir="ltr">&lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</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"><span class="">&gt; The proposal is well thought out and makes a valiant attempt at handling all of the issues necessary.  But I don&#39;t support it for a number of reasons.  I think it highlights how awkward it would be to try to address shadowing on a case-by-case basis, which isn&#39;t necessarily obvious until you explore what a solution might look like.<br>
<br>
</span>It does, but I&#39;m just not sure what else you can do about it. If there&#39;s a warning, you need a way to silence it. If you ignore some cases (like creating a conflict by importing two modules), you&#39;ll miss some of the subtlest and hardest-to-fix bugs.<br>
<br>
Honestly, I&#39;m tempted to say &quot;you just can&#39;t ever shadow a final protocol method&quot; and be done with it. If that prevents certain conformances or stops certain imports, so be it. You can always work around that with wrapper types or other techniques.<br></blockquote><div><br></div><div>You know, I think this might be cleverest solution. It adds a small limit to the language, but it doesn&#39;t unduly penalize retroactive modeling. If you control either the protocol or the conforming type, you can change the name of one of the methods so it doesn&#39;t shadow/get shadowed by the other.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
&gt; (And btw, &#39;final&#39; in this proposal is not exactly, because when combined with @incoherent the methods are not actually &#39;final&#39; - there is a necessary escape hatch).<br>
<br>
</span>There is no particular reason you couldn&#39;t allow similar annotated shadowing of `final` methods on classes; they would have basically the same semantics as you get here, where if a piece of code knows it&#39;s working with the subclass you get subclass semantics, but otherwise you get superclass ones. I do not claim this is a good idea. :^)<br>
<span class=""><br>
&gt; Second, we should require annotation of methods in protocol extensions that are not default implementation of requirements.  Maybe &#39;shadowable&#39; or &#39;staticdispatch&#39;?  These are awkward, but so is the behavior and they describe it better than anything else I&#39;ve seen so far (maybe we can do better though).<br>
<br>
</span>I don&#39;t think `shadowable` makes sense here; that doesn&#39;t acknowledge a limitation, which is what we&#39;re trying to do here.<br>
<br>
I continue to wish we hadn&#39;t taken `static` for statically-dispatched type methods. But I lost that argument years before swift-evolution became a thing.<br>
<span class=""><br>
&gt; I don&#39;t like &#39;nondynamic&#39; both because it is not aligned with the meaning of &#39;dynamic&#39; and also because it only says what the behavior *is not* rather than what the behavior *is*.<br>
<br>
</span>I do understand what you mean here. Unfortunately, the word &quot;virtual&quot; in a keyword makes me break out in hives, and I&#39;m not sure what else we might base it on.<br>
<br>
This is why I selected `final` in my proposal. `final` is desperately close to the actual semantic here, far closer than anything else in the language.<br></blockquote><div><br></div><div>How about `nonoverridable`? That said, I agree with earlier comments that training-wheel annotations probably aren&#39;t the way to go. Maybe, as you suggest above, just don&#39;t allow shadowing at all.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5"><br>
--<br>
Brent Royal-Gordon<br>
Architechies<br>
<br>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</div></div></blockquote></div><br></div></div>