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

[Kevin Ballard]

On Wed, Dec 9, 2015, at 04:09 PM, Brent Royal-Gordon wrote:

> 2) Swift’s general slant is towards using virtual dispatch unless it’s forbidden. (Leaving aside cases where the optimizer can prove at compile time what a dynamic dispatch would do.) That’s why we have a `final` keyword instead of a `virtual` keyword. Because of this, it’s not surprising to Swift users that you *can* override some extension methods; rather, the surprise is that you *can’t* override others. (And the *real* surprise is that you can kind-of-but-not-really override them, and Swift doesn’t complain.) I want developers to mark the surprise.

I don't agree that Swift's general slant is towards using virtual dispatch. Only classes and protocol objects use virtual dispatch[1]. And Swift even provides a mechanism (final / static) to remove dynamic dispatch from classes. It seems to me that Swift's general slant is towards encouraging static dispatch whenever possible.

[1] Generic types bounded by protocols is a borderline case. Semantically, they use static dispatch. In optimized builds, specializations are produced for the various type parameterizations that use static dispatch (although a generic virtual dispatch version is still emitted too, but I don't know when that's ever used). I assume the virtual dispatch is done just for the sake of improving compile times (by not having to generate the specializations), but to the best of my knowledge there's no behavioral difference here and it should be indistinguishable from static dispatch

-Kevin Ballard