<div dir="ltr">Could you provide an example? I tried playing with protocol extensions, modelling this situation:<div><br></div><div>> If an extension method collision occurs when a type implements multiple protocols, </div><div><br></div><div>but so far all examples I found where one would see a collision are disallowed by compiler, e.g.</div><div><br></div><div><div><br></div><div>protocol P1 {</div><div> func something() -> Int</div><div>}</div><div><br></div><div>protocol P2 {</div><div> func something() -> Int</div><div> func another() -> Int</div><div>}</div><div><br></div><div>extension P1 {</div><div> </div><div> func something() -> Int {</div><div> return 1</div><div> }</div><div><br></div><div> func another() -> Int {</div><div> return 1</div><div> }</div><div>}</div><div><br></div><div>extension P2 {</div><div> </div><div> func something() -> Int {</div><div> return 2</div><div> }</div><div> </div><div> func another() -> Int {</div><div> return 2</div><div> }</div><div>}</div><div><br></div><div>class C1: P1 { // <- P1, P2 here doesn't compile</div><div><br></div><div> func something() -> Int {</div><div> return 0</div><div> }</div><div> </div><div>}</div><div><br></div><div>class C2: P2 {</div><div> </div><div>}</div><div><br></div><div>class C3: P1, P2 {</div><div><br></div><div> func something() -> Int {</div><div> return 0</div><div> }</div><div> </div><div> func another() -> Int {</div><div> return 0</div><div> }</div><div> </div><div>}</div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Dec 7, 2015 at 7:17 AM, Paul Cantrell 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">One of the few things in Swift 2 that feels to me like a design flaw is the way Swift mixes static and dynamic method dispatch.<br>
<br>
Alexandros Salazar gives an excellent explanation of this problem — and I agree wholeheartedly with his title for the article:<br>
<br>
<a href="http://nomothetis.svbtle.com/the-ghost-of-swift-bugs-future" rel="noreferrer" target="_blank">http://nomothetis.svbtle.com/the-ghost-of-swift-bugs-future</a><br>
<br>
The upshot is that when we see this:<br>
<br>
foo.bar()<br>
<br>
…it’s very hard to know how the compiler will determine which implementation of bar() to use. It might use static dispatch; it might use dynamic dispatch.<br>
<br>
The rules that govern this are arcane, and hard to remember. They have the feeling of being a “gotcha” question for job interviews — always a red flag for language features.<br>
<br>
Even if you remember the rules, the information needed to determine whether dispatch is static or dynamic is hard to track down. It depends on whether bar()’s implementation comes from an extension, whether the extension method appeared on the extended protocol, and whether the inferred type of foo is the protocol itself or an implementing type.<br>
<br>
A crucial part of the meaning of “foo.bar()” is implicit, and hard to determine. This runs contrary to Swift’s stated goal of prioritizing clarity at the point of API use, and its general pattern of making intent explicit. And it feels dangerous — a wellspring of insidious bugs.<br>
<br>
Thus:<br>
<br>
<br>
PROPOSAL<br>
<br>
Make the syntax “foo.bar()” always use dynamic dispatch, i.e. always use _only_ the runtime type of foo to determine which implementation of bar() to use. If an extension method collision occurs when a type implements multiple protocols, require the type to explicitly specify which one to use (as Swift already requires the caller to do at the point of invocation).<br>
<br>
<br>
I mean this proposal somewhat as a strawman. It’s such an obvious choice, I’m sure there were good reasons not to do it. But I’d like to propose the obvious solution in order to understand what’s wrong with it. I realize static dispatch precludes some optimizations, but I doubt that this alone drove the design choice. I see no safety or expressiveness upside to the way it works now.<br>
<br>
Cheers,<br>
<br>
Paul<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>
</blockquote></div><br></div>