<div dir="ltr">Thanks for the explanation Adrian, I also had to Google this :)<div><br></div><div>Personally I'd love some kind of solution that would prevent this confusion of why this method does different things when called on the same object in two different ways, but I don't have any ideas how this could be solved... It's something that most people learning Swift definitely won't expect to work as it works now (unless they're coming from a language that mostly works with static dispatch, but I'm guessing most people won't).</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 11 April 2017 at 15:50, Adrian Zubarev via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></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"><div class="m_-6628385599181561046bloop_markdown"><p>I myself pitched that requirement quite a few times on the list. Thank you, finally I understood why it’s not possible. Now I fully agree that the requirement of an override should not exist for the base type conforming to the protocol.</p>
<p>For those who might misunderstand the concept of retroactive conformances just like I did it, here is a quick snippet for you. </p>
<p>Imagine you’re working on some iOS project and for some reason you need an existential that only knows a property <code>title</code> of type <code>String?</code>.</p>
<pre><code class="m_-6628385599181561046swift">protocol P { var title: String? { get set } }
</code></pre>
<p>Now you could retroactively conform types that already have this property to that protocol <code>P</code> without the need of implementing the property yourself. Think of it as a backdoor. ;)</p>
<pre><code class="m_-6628385599181561046swift">extension UIViewController : P {} // This just works
</code></pre>
<p>The proposed solution will simply break this nice feature.</p><span class="HOEnZb"><font color="#888888">
<p></p></font></span></div><div class="m_-6628385599181561046bloop_original_html"><span class="HOEnZb"><font color="#888888"><div id="m_-6628385599181561046bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto"><br></div> <br> <div id="m_-6628385599181561046bloop_sign_1491918026451542784" class="m_-6628385599181561046bloop_sign"><div style="font-family:helvetica,arial;font-size:13px">-- <br>Adrian Zubarev<br>Sent with Airmail</div></div></font></span><span class=""> <br><p class="m_-6628385599181561046airmail_on">Am 11. April 2017 um 00:52:01, Xiaodi Wu via swift-evolution (<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>) schrieb:</p> <blockquote type="cite" class="m_-6628385599181561046clean_bq"><span><div><span style="color:rgb(0,0,0);font-family:helvetica;font-size:13px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;display:inline!important;float:none">Requiring `override` breaks retroactive conformance of types to protocols. This idea has been brought up over half a dozen times. Each time it fails in not being able to accommodate retroactive conformance.</span></div></span></blockquote></span></div><div class="m_-6628385599181561046bloop_markdown"><p></p></div></div><br>______________________________<wbr>_________________<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/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br>
<br></blockquote></div><br></div>