[swift-evolution] [Pitch] Changing NSObject dispatch behavior

[Goffredo Marocchi]

Sent from my iPhone

> On 29 Dec 2016, at 23:50, Freak Show via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
>> On Dec 29, 2016, at 13:28, Rod Brown via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> I’m in agreement that ‘dynamic’ is probably not what you want without a declaration.
> 
> I hold a completely opposite viewpoint.  Dynamic is always what I want and table based is premature optimization.  

Succinctly stated, unless the compiler can guarantee that conversion to table based dispatch or static dispatch has absolutely no consequence on the code behaviour or the user has explicitly asked for such an optimisation to happen or fully dynamic should be the default.

I cannot understand why one should like code to go back to having behaviour being decided by the pointer/reference type instead of what the instance created actually holds, but this will not change anytime soon.

> Late binding is important.  I found far too often when working in C++ (yes I am really flipping old) I would come across code where a developer hadn't chosen to make a method virtual and I found myself just up a creek with regards to extending that code.  Ditto people declaring stuff final in Java for no good reason.
> 
> The important thing to consider is that the future is generally unknowable and if you don't know the future you cannot make good choices about what should and should not be dynamic.  So the conservative thing is to make everything dynamic until you cannot afford it - which...is usually never.
> 
>> The only difference between table and method dispatch is the Objective-C message dispatch system. Unless users want to work around things by manually handling with some of the complex machinery in Obj-C, which is rare, then there is no reason behind doing so, and all it comes down to is a relatively large performance hit for nothing. And to be honest, with very few exceptions, if you’re using that ultra-dynamic machinery, you’re probably Doing It Wrong in the first place.
> 
> I do this sort of thing routinely and I assure you I am not Doing It Wrong.
> 
> I don't get why there is so much emphasis on performance in this day and age.  I haven't run into a performance problem I could trace to speed of ObjectiveC's method dispatching since the early 90's.
> 
> Second - I have quite a lot of code that relies on this sort of dynamism. I've been a very serious C++ developer and a very serious Smalltalk programmer at various times in my career and I value the flexibility of late binding far above performance.
> 
>> If you need this functionality, dynamic still exists. But Swift is Table Dispatch by default for a reason: you’re paying a massive penalty for something you’ll rarely if ever use, and it should be opt in.
> 
> Strongly disagree.  
>> 
>> 
>>> On 15 Dec 2016, at 10:15 am, Brian King via swift-evolution <swift-evolution at swift.org> wrote:
>>> 
>>> I wanted to follow up to a blog post I wrote about Message Dispatch in
>>> Swift — https://www.raizlabs.com/dev/2016/12/swift-method-dispatch. I
>>> mentioned some changes to NSObject that didn’t result in any
>>> objections, so I thought it was time to see what the SE mailing list
>>> thought.
>>> 
>>> I’ve read a few conversations on SE mailing list that have morphed
>>> into abstract conversations about dynamic vs static dispatch. I want
>>> to focus specifically on how Swift NSObject subclasses behave.
>>> 
>>> I think that there are 2 changes that will result in fewer bugs and
>>> will not have a substantial impact on performance:
>>> 
>>> 
>>> ## Remove Table Dispatch from NSObject
>>> 
>>> NSObject subclasses use table dispatch for the initial class
>>> declaration block. I think that using message dispatch for NSObject
>>> subclasses everywhere will result in a much more consistent developer
>>> experience.
>>> 
>>> ## Block NSObject Visibility Optimizations
>>> 
>>> Swift upgrades method dispatch to final when the compiler can prove
>>> that the method is not subclassed. I would like to see Swift be more
>>> careful about the impact of these optimizations on message dispatch,
>>> and consider message dispatch non-upgradable.
>>> 
>>> 
>>> I thought it would help to frame this choice as a trade-off between
>>> Swift’s goals of safe, fast, and expressive.
>>> 
>>> ## Safe
>>> 
>>> Always using message dispatch for NSObject subclasses will fix a class
>>> of runtime errors in framework features that are designed around
>>> message passing (e.g. KVO). Arguments against using dynamic features
>>> like this are valid, but Cocoa frameworks still use dynamic features
>>> and the above behaviors result in actual bugs. As a bonus, this will
>>> resolve SR-584, where a table-dispatched method that is overridden by
>>> a message dispatch method doesn’t behave correctly.
>>> 
>>> ## Fast
>>> 
>>> The above changes will result in slower dispatch in NSObject
>>> subclasses. However, I don't think that these dispatch changes
>>> actually have a tangible impact on performance. Most NSObject
>>> subclasses sit on top of a lot of `objc_msgSend`, and if there is a
>>> specific hot spot, it would still be optimizable via the final
>>> keyword.
>>> 
>>> ## Expressive
>>> 
>>> Using table dispatch for NSObject without any source indication or
>>> library documentation is not very expressive. I think it’s important
>>> to weigh table dispatch behavior against all of the framework
>>> documentation and developer experience that assume message dispatch.
>>> This will also eliminate the need for a lot of `@objc` and `dynamic`
>>> annotations that are often inconsistently applied depending on if they
>>> are needed in the scope they are defined in (e.g. class vs extension).
>>> 
>>> 
>>> If this idea shows promise, I’d be glad to formalize a Swift Evolution
>>> Proposal and explore syntactic details. I think being able to flag a
>>> class with `dynamic` and applying this flag to `NSObject` may be the
>>> only syntactic change needed. However, it would be good to debate the
>>> merit of the behavior change before the syntax.
>>> 
>>> 
>>> Thanks!
>>> 
>>> 
>>> Brian King
>>> _______________________________________________
>>> 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
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution