[swift-evolution] [Mini-proposal] Require @nonobjc on members of @objc protocol extensions

Greg Parker gparker at apple.com
Tue Jan 5 20:29:12 CST 2016

> On Jan 5, 2016, at 3:37 PM, Charles Srstka via swift-evolution <swift-evolution at swift.org> wrote:
>> On Jan 5, 2016, at 11:52 AM, Douglas Gregor <dgregor at apple.com <mailto:dgregor at apple.com>> wrote:
>> There are better mechanisms for this than +load. But one would have to deal with the dylib loading issue and the need to enumerate root classes to get to a complete implementation. Frankly, I don’t think this level of Objective-C runtime hackery is worth the effort, hence my suggestion to make the existing behavior explicit.
> Yeah, +load was just to throw together a quick-and-dirty demonstration, and not what you’d actually use. You have a point about libraries and bundles; you’d have to hook into that and rescan each time new code was dynamically loaded. However, the enumeration of classes only seems to take around 0.001 seconds, so I don’t think it’s terrible.

Enumeration of classes is terrible: it forces the runtime to perform lots of work that it tries very hard to perform lazily otherwise. I would expect your measured cost to be much higher if you had linked to more high-level libraries (UIKit, MapKit, etc).

Greg Parker     gparker at apple.com     Runtime Wrangler

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160105/6999243a/attachment.html>

More information about the swift-evolution mailing list