[swift-evolution] Final by default for classes and methods

[Brent Royal-Gordon]

> I don't agree with this framing.  IMO it encourages alternative designs emphasizing protocols and composition.  This is a very good thing IMHO.  I like to think of inheritance is a tool is last resort. 

It does also do this...

> BTW, I am planning a future proposal regarding automatic forwarding which if accepted would make the use of protocols and composition more convenient.

And this is a worthy goal.

But neither of these things has any bearing on the fact that sometimes, the library author just flat-out messes it up. And when they do, your choices are often to override something that's not meant to be overridden, or to reimplement the functionality yourself. All the protocols and composition in the world can't fix that.

(I do wonder, though, if we can have the fixability we need without the danger. Imagine if Swift included some facility to override a broken member even in a sealed class, but only for a particular version. So you could override a broken method on iOS 9.1, but the patch wouldn't be applied on 9.2 unless you tested it there and annotated your code to indicate the patch was also needed in that version.)

-- 
Brent Royal-Gordon
Architechies