
Method dispatch in Swift - adamnemecek
https://www.raizlabs.com/dev/2016/12/swift-method-dispatch/
======
CalChris

      Java uses table dispatch by default, but you can opt into
      direct dispatch by using the final keyword. C++ uses direct
      dispatch by default, but you can opt into table dispatch by
      adding the virtual keyword. Objective-C always uses message
      dispatch, but allows developers to fall back to C in order
      to get the performance gains of direct dispatch. Swift has
      taken on the noble goal of supporting all three types of
      dispatch.
    

I kinda already knew this but it's nice and succinct.

~~~
jcrites
> Most languages support one or two of these. Java uses table dispatch by
> default, but you can opt into direct dispatch by using the final keyword.

This is not accurate. Java does not use table dispatch by default. The HotSpot
compiler will optimize most code to use direct dispatch, reserving table
dispatch only for cases where calls cannot be inlined; and final does not
particularly enable direct dispatch.

A discussion of these issues:
[http://www.ibm.com/developerworks/java/library/j-jtp1029/ind...](http://www.ibm.com/developerworks/java/library/j-jtp1029/index.html)

> Like many myths about Java performance, the erroneous belief that declaring
> classes or methods as final results in better performance is widely held but
> rarely examined. The argument goes that declaring a method or class as final
> means that the compiler can inline method calls more aggressively, because
> it knows that at run time this is definitely the version of the method
> that's going to be called. But this is simply not true. Just because class X
> is compiled against final class Y doesn't mean that the same version of
> class Y will be loaded at run time. So the compiler cannot inline such
> cross-class method calls safely, final or not. Only if a method is private
> can the compiler inline it freely, and in that case, the final keyword would
> be redundant.

> On the other hand, the run-time environment and JIT compiler have more
> information about what classes are actually loaded, and can make much better
> optimization decisions than the compiler can. If the run-time environment
> knows that no classes are loaded that extend Y, then it can safely inline
> calls to methods of Y, regardless of whether Y is final (as long as it can
> invalidate such JIT-compiled code if a subclass of Y is later loaded). So
> the reality is that while final might be a useful hint to a dumb run-time
> optimizer that doesn't perform any global dependency analysis, its use
> doesn't actually enable very many compile-time optimizations, and is not
> needed by a smart JIT to perform run-time optimizations.

~~~
drtse4
> Like many myths about Java performance, the erroneous belief that declaring
> classes or methods as final results in better performance is widely held but
> rarely examined.

Yes, was about to point this out, one of the more resilient misconceptions
about Java. I've lost count of how many times I had to explain this and remove
a boatload of unnecessary "final".

------
dep_b
They did a great job of almost plastering over all the typical Objective-C and
Cocoa things in Swift but you can't escape some of these weird underlying
mechanisms of Objective-C creeping in without sacrificing compatibility.

Great read, good to know this stuff. I encountered a few of these examples
while poking around with more complex features in the language.

~~~
melling
Makes you wonder how long before Apple stops making the compromises in
compatibility. In the near term, sure, but 3-5 years down the road, they may
favor Swift.

~~~
pjmlp
They already do.

All the recent Objective-C features were added to improve the compatibility
between both languages, reducing Objective-Cisms in Swift.

~~~
dep_b
I noticed that nullable nonnull did almost nothing for my Objective-C code. A
real bummer, I would love to have a good analyzer warning for that.

------
duaneb
I must say, while swift can be very readable, just reading through this
article put me off of the language. If you don't work with objective-c or
uikit/cocoa, is there a reason to use this over another llvm-based language
with cleaner, simpler semantics? The two bugs outlined are terrifying.

~~~
fredsir
Which other llvm-based language to you recommend? Swift is, to me, elegant and
intuitive to use, quick to write, and supports a lot of nice features which
you don't find in say C++, and supports stuff that, say, Rust lacks support
for.

`Optional`s being baked into the language, using `Result` types, `guards`, `if
let`, pattern matching, great support for Rx, and lots of other fun and cool
stuff, easy use of high-level features with possibility to dive deeper, while
still being able to use all the features of Cocoa, Cocoa Touch, and all the
other frameworks and features of macOS, iOS, watchOS, and appletvOS as a
native citizen, and also write code that runs better everyday on Linux, is a
really great package. Swift Package Manager is also great and becomes better
everyday.

Swift is a good combination of a great language that supports a lot of cool
platforms and has a lot of tools available.

------
falsedan
Funny, the description of message-passing dispatch is the same as Perl's &
Python method resolution, including the caching of recently-resolved methods
for fast direct dispatch…

------
twoodfin
Can anyone explain the etymology of "witness table"?

~~~
johncolanduoni
The only analogy I can think of is to a "witness" to a logical proposition in
mathematics. In this case the witnesses "prove" that the given concrete type
implements the given abstract type.

If that's the case it's kind of a weird way to put it, though it sort of
squares with the witnesses in proof-relevant formulations of logout where you
care about the form of a proof and not just what it proves.

------
the_duke
Now I just wish that you get get Swift in Arch...

The AUR packages are broken without downgrading llvm which I can't do atm, and
there are no prebuilt generic linux versions... -.-

~~~
drewcrawford
The problem with Arch is that Swift relies quite heavily on Glibc so the work
to port to alternate libc is very substantial.

The other problem is that the mess basically _starts_ there, e.g. Swift
programs in practice also depend on Glibc and so after you kill the first
turtle it's still turtles all the way down.

You could build an Arch with Glibc, but why you would want to is not
immediately clear.

~~~
mwcampbell
I think you're confusing Arch with Alpine. Alpine is based on musl; Arch is
based on glibc.

