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

[Greg Titus]

> On Dec 21, 2015, at 11:50 AM, Jordan Rose via swift-evolution <swift-evolution at swift.org> wrote:
> 
> - There's a difference between "we're not going to optimize" and "we're not going to optimize now". Objective-C's "everything uses objc_msgSend" model is essentially unoptimizable. It's not that the developer can't work around that when performance is necessary; it's that the resulting code doesn't feel like Objective-C. Swift can do better, and even with its current semantics it does do better, for free. (And optimizations in frameworks are incredibly important. Where do you think your app spends most of its CPU time? I would guess for many many non-game apps, it's in framework code.)
> 
> - A major goal of Swift is safety. If you are writing a safe type built on unsafe constructs (like, say, Array), it is imperative that you have some control over your class invariants to guarantee safety. At the same time, your clients shouldn't have to know that you're built on unsafe constructs.
> 
> That last one is really the most important one. If you replace a method on someone else's class, you don't actually know what semantics they're relying on. Of course Apple code will have bugs in it. Trying to patch over these bugs in your own code is (1) obviously not an answer Apple would support, but also (2) fraught with peril, and (3) likely to break in the next OS release.
> 
> TLDR: It's already unsafe to do this with the existing set of Swift features. Yes, this makes things "worse", but it's not something we're interested in supporting anyway.

I think this is potentially getting beyond Swift language development and into much wider platform concerns, and so I realize that I’m perhaps arguing at the wrong level and in the wrong place. Sorry about that. That having been said:

There is a really big design difference between a library like Swift’s stdlib or Foundation, which have fairly straightforward interfaces and simple program flow in and out. (In both of these cases you generally call in, and any calls out to application code are explicit and mostly short-lived closures.) AppKit or UIKit, on the other hand, are incredibly porous and have quite complicated program flow between the framework and the application code. The framework design is more like a skeleton upon which the application code hangs, and which in turns moves the kit objects about, rather than a self-contained system with a lot of invariants. 

I can’t prove any causation, but I would certainly argue that the dynamic nature and possible overridability of even things that Apple doesn’t specifically intend to allow overriding is one of the primary reasons why AppKit has survived for 20+ years and spawned arguably the most successful application framework in history in UIKit. On the other hand, efficiency and safety have rarely been major issues.

TLDR: I don’t think using the design trade-offs of Array (which is, after all, a value type and can’t be subclassed anyway) inside stdlib, can be very usefully broadened to apply to reference types in application frameworks. 

	- Greg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151221/331d3248/attachment.html>