<br><br>On Tuesday, December 8, 2015, Paul Cantrell via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> The ability to use static dispatch in most cases is one of the great features of Swift, and it's something that needs to be preserved, not relegated to being an optimization that can be done occasionally.<br>
<br>
Can you think of a situation where that’s the desired semantics, as opposed to either a desirable optimization or a confusing workaround for the “monkey collision” problem? (I can’t see the use case, but I’m open to hearing it!)<br>
<br></blockquote><div><br></div><div>Sure, private protocol extension. For example, </div><div><br></div>public protocol Animal {<div> func greet()</div><div> func sit()</div><div> func run()</div><div>}</div><div><br></div><div>private extension Animal {</div><div> func compete() { greet(); sit(); run()}</div><div>}</div><div><br></div>// we are provided with animal <span></span><br><div>... animal.compete()...</div><div><br><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> It's also worth noting that the current behavior, where methods defined in protocol extensions can't be overridden by the implementing type, may actually be the desired behavior in many cases.<br>
<br>
If you don’t want a method to be overridable, that’s what “final” is for.<br>
<br>
The current behavior, in which a method is silently shadowed, does not seem to be to be a desirable behavior in any situation. The compiler warnings/errors Joe Groff proposed seem like a bare minimum, but I’d prefer to eliminate the situation that needs to be warned about in the first place.<br>
<br>
Cheers, P<br>
<br>
> On Dec 7, 2015, at 4:11 PM, Kevin Ballard via swift-evolution <<a href="javascript:;" onclick="_e(event, 'cvml', 'swift-evolution@swift.org')">swift-evolution@swift.org</a>> wrote:<br>
><br>
> I'd love to see these two key things that Joe mentioned get added.<br>
> Diagnostics around confusing situations is a good idea (although there<br>
> needs to be a way to disable it too; what if I intentionally need to use<br>
> the same name in a type and in an extension to one of the conformed-to<br>
> protocols, for various reasons?).<br>
><br>
> I can't support the original proposal though, of making foo.bar() use<br>
> dynamic dispatch. The ability to use static dispatch in most cases is<br>
> one of the great features of Swift, and it's something that needs to be<br>
> preserved, not relegated to being an optimization that can be done<br>
> occasionally.<br>
><br>
> It's also worth noting that the current behavior, where methods defined<br>
> in protocol extensions can't be overridden by the implementing type, may<br>
> actually be the desired behavior in many cases. Heck, the ability to<br>
> trigger this different behavior is one of the three reasons to even<br>
> define methods in protocol extensions instead of in the protocol (the<br>
> others being when you're defining it for a subset of protocol<br>
> implementations, and when you're defining extensions on protocols<br>
> imported from other modules). Removing this functionality (by making<br>
> foo.bar() always dynamic) means reverting back to the Swift 1.x<br>
> convention of having global functions to provide this behavior.<br>
><br>
> I wouldn't mind seeing something like the `dynamic` keyword to allow<br>
> concrete types to override these protocol extension methods (although<br>
> `dynamic` in this case would not imply @objc, like it does today, which<br>
> may be a little confusing), but that would be opt-in behavior.<br>
><br>
> -Kevin Ballard<br>
><br>
> On Mon, Dec 7, 2015, at 12:14 PM, Joe Groff via swift-evolution wrote:<br>
>> The main reason to constrain dynamic dispatch is modularity. The problems<br>
>> of interfering categories or monkey-patches in languages like ObjC and<br>
>> Ruby with late-bound dispatch and open classes are well-known. In Swift's<br>
>> model, it isn't possible for an extension in one module to interfere with<br>
>> existing protocol conformances or class hierarchies at runtime (except<br>
>> with @objc of course). Modules need to be compiled together to be aware<br>
>> of each other to interact with each other's interfaces.<br>
>><br>
>> The particular example Alexandros brings up is more an artifact of our<br>
>> existing implementation than desirable behavior. Two key things are<br>
>> missing:<br>
>><br>
>> - the ability for extensions to protocols to add new<br>
>> dynamically-dispatched methods, and<br>
>> - compiler quality work to diagnose confusing cases where concrete types<br>
>> obviously shadow non-dynamic protocol extensions.<br>
>><br>
>> There is a related behavior change proposal Doug Gregor's been working on<br>
>> for classes, to have conforming to a protocol implicitly re-declare all<br>
>> the protocol's methods as class methods, so that they can be overridden<br>
>> by subclasses in the expected way.<br>
>><br>
>> -Joe<br>
>><br>
>>> On Dec 6, 2015, at 8:17 PM, Paul Cantrell via swift-evolution <<a href="javascript:;" onclick="_e(event, 'cvml', 'swift-evolution@swift.org')">swift-evolution@swift.org</a>> wrote:<br>
>>><br>
>>> 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" 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="javascript:;" onclick="_e(event, 'cvml', 'swift-evolution@swift.org')">swift-evolution@swift.org</a><br>
>>> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
>><br>
>> _______________________________________________<br>
>> swift-evolution mailing list<br>
>> <a href="javascript:;" onclick="_e(event, 'cvml', 'swift-evolution@swift.org')">swift-evolution@swift.org</a><br>
>> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
> _______________________________________________<br>
> swift-evolution mailing list<br>
> <a href="javascript:;" onclick="_e(event, 'cvml', 'swift-evolution@swift.org')">swift-evolution@swift.org</a><br>
> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
<br>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="javascript:;" onclick="_e(event, 'cvml', 'swift-evolution@swift.org')">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</blockquote></div>