[swift-evolution] Static Dispatch Pitfalls

Matthew Johnson matthew at anandabits.com
Sat May 21 08:23:05 CDT 2016



Sent from my iPad

> On May 21, 2016, at 7:17 AM, Charlie Monroe <charlie at charliemonroe.net> wrote:
> 
> Yes, see below. I believe it should work as sketched below. Making the extension default implementations final will prevent from extending the delegate protocols by subclasses (and much more).
> 
> IMHO the default dispatch for methods on protocol extensions should be dynamic.

This has been discussed extensively and is problematic for a number of reasons.  

> 
>> This thread isn't default implementations of protocol requirements.  Those are dynamically dispatched.  This thread is about *new* methods introduced in protocol extensions.  These are not dynamically dispatched and exhibit different behavior depending on the static type due to the shadowing issue.
>> 
>>> 
>>> You might argue that you mean just the methods declared only in the protocol extension - I see those, however as something that may help subclassing delegated instances. Example:
>>> 
>>> You have a root class representing some kind of a view - it has a `delegate` property. Then you decide to make a subclass and would like to introduce your own delegate methods on top of those offered by the superclass.
>>> 
>>> You can subclass the protocol, but Swift won't let you override the `delegate` property with a different type. So you can create a new property `mySubclassDelegate`, which is horrid, but kinda works.
>>> 
>>> The other option is to simply extend the original delegate protocol with additional methods with default implementation, which you should be able to override in your conforming class.
>>> 
>>> In code example:
>>> 
>>> protocol Delegate {
>>>  func myClassDidSomething(obj: MyClass)
>>> }
>>> 
>>> class MyClass {
>>>  weak var delegate: Delegate?
>>> }
>>> 
>>> extension Delegate {
>>>  func mySubclassDidSomethingElse(obj: MySubclass) { }
>>> }
>>> 
>>> class MySubclass: MyClass { }
>>> 
>>> This is where I see how this can be very useful in many areas not having it final.
>>> 
>>> Charlie
>>> 
>>>> Many moons ago, I was pushing to require a `final` keyword on protocol extension methods, which would prevent conforming types from providing their own implementations. It was probably the first thing I worked on. There were long arguments about whether and how you could override the `final`-ness, people kept clamoring for dynamic dispatch, and I ultimately wasn't able to produce a consensus before I had to turn my attention back towards paying work.
>>>> 
>>>> -- 
>>>> Brent Royal-Gordon
>>>> Architechies
>>>> 
>>>> _______________________________________________
>>>> swift-evolution mailing list
>>>> swift-evolution at swift.org
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>> 
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 



More information about the swift-evolution mailing list