> On Mar 29, 2017, at 4:24 PM, Charles Srstka <[email protected]> wrote: > >> On Mar 29, 2017, at 3:41 PM, Greg Parker <[email protected]> wrote: >> >>> On Mar 29, 2017, at 9:02 AM, Charles Srstka <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>>> On Mar 29, 2017, at 10:51 AM, Jens Alfke <[email protected] >>>> <mailto:[email protected]>> wrote: >>>> >>>>> On Mar 29, 2017, at 6:57 AM, Daryle Walker <[email protected] >>>>> <mailto:[email protected]> <mailto:[email protected] >>>>> <mailto:[email protected]>>> wrote: >>>>> >>>>> Now the new Xcode release notes say that “• Swift now warns when an >>>>> NSObject subclass attempts to override the initialize class method, >>>>> because Swift can't guarantee that the Objective-C method will be called. >>>>> (28954946)” >>>> >>>> Huh, I haven’t heard of that. And I’m confused by “the Objective-C method” >>>> — what’s that? Not the +initialize method being compiled, because that’s >>>> in Swift. The superclass method? >>>> >>>> Guess I’ll follow that Radar link and read the bug report myself. Oh, >>>> wait. :( >>> >>> You actually can this time, since Swift’s bug reporter is actually open to >>> the public. https://bugs.swift.org/browse/SR-3114 >>> <https://bugs.swift.org/browse/SR-3114><https://bugs.swift.org/browse/SR-3114 >>> <https://bugs.swift.org/browse/SR-3114>> >>> >>> Basically, with Whole Module Optimization turned on, +initialize wasn’t >>> getting called. Their solution was to just get rid of +initialize. >> >> You don't even need WMO. Many arrangements of Swift code can bypass ObjC >> +initialize. >> >> Invocation of +initialize is a feature of objc_msgSend(). Swift code does >> not always use objc_msgSend() when calling methods: some methods are >> inlined, some are called via virtual table, some are called directly. None >> of these paths will provoke +initialize. >> >> Changing Swift's generated code to guarantee +initialize would be >> prohibitively expensive. Imagine an is-initialized check in front of every >> inlined call. It would be more expensive than +initialize in ObjC because >> +initialize checking is free once you pay the cost of objc_msgSend(). (The >> ObjC runtime checks +initialize on uncached dispatch, and never caches >> anything until +initialize completes. Most dispatches are cached so they pay >> nothing for +initialize support.) >> >> +initialize in Swift isn't safe and is too expensive to make safe, so we're >> taking it away instead. > > I wonder if an equivalent Swift-native feature could be added, something like > a typeInit block? If the block weren’t there, nothing special would happen, > and if the block were present, the compiler could basically generate the code > in the example I gave, but add the static var access to the front of every > initializer and static/class member. That shouldn’t impact performance too > much, and wouldn’t impact at all in the case that there’s no type initializer.
I hope so as well. My favorite candidate so far would be a reflection capability to get a list of all classes/structs/enums adhering to a protocol. Then you could build your own initializable protocol fairly easily (and can even build whatever facility you want to guarantee a particular ordering or timing). The reason, I favor it over a specific method, is that it also enables a bunch of other cool patterns like extensible factories, and easy plug-ins. _______________________________________________ Cocoa-dev mailing list ([email protected]) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [email protected]
