> On Dec 21, 2015, at 11:50 AM, Jordan Rose via swift-evolution
> <[email protected]> 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_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
