<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Dec 21, 2015, at 11:50 AM, Jordan Rose via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class=""></div><div class="">- There's a difference between "we're not going to optimize" and "we're not going to optimize <i class="">now"</i>. 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 <i class="">does</i> do better, for free. (And optimizations in frameworks are <i class="">incredibly</i> 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.)</div><div class=""><br class=""></div><div class="">- A major goal of Swift is safety. If you are writing a safe type built on unsafe constructs (like, say, Array), it is <i class="">imperative</i> 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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div></div></div></blockquote></div><br class=""><div class="">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:</div><div class=""><br class=""></div><div class="">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. </div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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. </div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>- Greg</div></body></html>