[swift-evolution] Proposal: Universal dynamic dispatch for method calls

[Paul Cantrell]

> Method invocation syntax does not inherently mean "dynamic dispatch" any more than function syntax does.

In languages now in widespread use — Java, Ruby, Javascript, C#, what I know of Python — that is _precisely_ what it means. In all those languages, as far as I know:

all uses of the dot invocation syntax either use dynamic dispatch, or have something on the left whose compile-time and runtime types are identical; and
all instances of dynamic dispatch in the language either use the dot invocation syntax, or have and implicit “self.” / “this.”  that uses it.

In short, programmers are likely to bring to Swift the assumption that dot invocation = dynamic dispatch.

Our difference of perspective on this single point [rimshot] is probably the source of our larger disagreement on this entire thread.

Cheers, P


> On Dec 10, 2015, at 6:31 PM, Kevin Ballard via swift-evolution <swift-evolution at swift.org> wrote:
> 
> On Thu, Dec 10, 2015, at 02:24 AM, Brent Royal-Gordon wrote:
>> Swift loves to dispatch things statically and does so wherever possible. In some cases—such as value types not having inheritance—language features are clearly designed the way they are specifically to allow them to be statically dispatched. But Swift never uses static dispatch where dynamic dispatch would have given a different result. This contrasts with, for instance, a non-virtual C++ method’s behavior of “ha ha ha, I’m just going to ignore your override for speed." You could write a Swift compiler which dispatched everything dynamically, and you would never see any difference in semantics.
> 
> Yes it does. When message dispatch is done using the obj-c runtime, the compiler is free to omit the message send and use static dispatch if it believes it knows the concrete type of the receiver. This normally behaves the same, because dynamic dispatch with a known receiver type and static dispatch are the same, except if the method is dynamically replaced using the obj-c runtime methods, the static dispatch will not invoke the dynamically overridden method. The most common way you see this is with KVO. If you try and KVO an @objc property on a Swift object, it may work sometimes and may not work at other times, depending on when the compiler believes it can safely use static dispatch. This is why Swift has a whole keyword called `dynamic` whose job is to say "no really, use dynamic dispatch for every single access to this method/property, I don't care that you know for a fact it's a Foo and not a subclass, just trust me on this".
> 
> More generally, I don't see there being any real difference between
> 
> extension Proto {
>    func someMethodNotDefinedInTheProto()
> }
> 
> and saying
> 
> func someFuncThatUsesTheProto<T: Proto>(x: T)
> 
> except that one is invoked using method syntax and one is invoked using function syntax. Method invocation syntax does not inherently mean "dynamic dispatch" any more than function syntax does.
> 
> -Kevin Ballard
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151210/e7f61001/attachment.html>