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

[Brent Royal-Gordon]

> Any thoughts on instead having to mark the default method implementations as `default`?

There are three reasons I like `final`:

1) It echoes the meaning of `final` in a class—“this is the implementation and you cannot provide any other”.

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.

3) Since, as I said, Swift’s slant is towards virtual dispatch, I think that if Swift eventually permits overriding of protocol extension methods, the overridable behavior should be the default, and the current static behavior should be something you request.

But this is not a terribly strong preference; `default` would be alright too. The more important point to me is that the user should acknowledge the weird behavior of shadowing a protocol extension method. In other words, I think the `@incoherent` annotation on the conformance is actually more important than the `final` or `default` keyword on the declaration.

> It still seems strange to me to consider a protocol extension that uses the `final` keyword, because a) protocols have nothing to do with classes and `final` means no subclassing

The way I see it, `final` in a class is a way of saying “All instances of this class (including subclasses) must use this implementation and cannot substitute a different one”. Similarly, `final` in a protocol means “All instances conforming to this protocol must use this implementation and cannot substitute a different one”.

That’s why @incoherent is important. It’s basically saying “I know there are final members in this type and I can’t really override them, but I want to shadow them anyway, even though the result is going to be kind of half-assed.” You could even imagine it being applied to superclasses, allowing you to shadow their `final` members in the same way you can shadow protocol extension methods.

> and b) methods defined in protocol extensions by definition can't be overridden already, so the `final` keyword is just sort of like saying "no really, I mean it, you can't do the thing you already can't do!”.

That is *exactly* the point of what I’m proposing. Just like the `override` keyword sort of says “no really, I mean it, I want to do the thing I’m doing!"

-- 
Brent Royal-Gordon
Architechies