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

[Rod Brown]

It comes down to a few issues:

1. Final exists in the language. This itself creates headaches for framework makers when their framework classes need to become “final” at a later stage. What do you do with the old subclasses in an app that shipped 5 years ago subclassing a now-final class?

2. Many believe that you should only subclass classes designed to be subclassed, due to safety concerns. This means that the onus should be on the developer to put it in, rather than assume it’s subclassable.

3. Many other developers wonder about whether that is wise when we, especially some of us iOS devs, create subclasses of classes that were not designed to be subclassed, and we view our reasons for doing so as legitimate as part of the creative process of breaking out of the assumed constraints of the standard class.

4. Performance improvements can be made if you know a class is final. Swift, attempting to be as performant as possible, can optimise if it knows everything in the list will be of a certain type, and can optimise further if it knows that it will be *exactly* a type, rather than potentially a subclass.

I think there have been a few discussed, but this is a summation.


> On 23 Dec 2015, at 10:45 AM, Felipe Cypriano via swift-evolution <swift-evolution at swift.org> wrote:
> 
> I could read the entire conversation because following the web archives is super unintuitive. So feel free to answer me with a bunch of links if you think my question was already answered.
> 
> Isn't this proposal solving a problem that in practice doesn't exist or isn't common enough to be worth a language level fix? I'm trying to find an example of a common problem - in any language - that would benefit by having final/sealed by default.
> 
> ---
> Felipe Cypriano
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151223/db3b046b/attachment.html>