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

[Austin Zheng]

Responses inline. 

On Dec 23, 2015, at 12:35 PM, Brent Royal-Gordon <brent at architechies.com> wrote:

>> If the frameworks are written in Swift, nothing is stopping Apple from slapping 'final' on all the classes they don't want developers to inherit from, even if the proposal is rejected; neither is there anything stopping them from making all their classes inheritable (if that happened to be what they wanted, which it isn't).
> 
> You cannot look at a language simply as a technical artifact. A language creates culture and shapes the systems written in it. It defines not only what is possible and what is not, but also what is preferred and what is discouraged. Defaults matter. If they didn't, people wouldn't be trying to change the default.

You're right that defaults matter, but that's not the point. The argument is that this proposal is bad because it will make future Apple frameworks less flexible than if nothing were done. I'm saying that's not the case; if Apple wants to write frameworks in Swift then they will most likely annotate their APIs however they want, whether with 'final' or 'inheritable' or whatever their internal policy on this matter is, regardless of whether this proposal is adopted. They already make intended usage clear in the documentation.

> Making `final` the default, or `sealed` the default, encourages the use of closed class hierarchies. It attempts to make inflexibility the preferred form of shared Swift code. I'm not sure that's the right thing to do.
> 

Protocols are a more general and arguably superior way of making shared code flexible. I understand and sympathize with the flexibility argument but I think pushing for better abstractions is worth it (and I understand why others disagree).

> -- 
> Brent Royal-Gordon
> Architechies
>