A further benefit of this scheme is that it makes the behavior of @objc on class members consistent between NSObject-derived and Swift-native classes. Right now, it is legal to apply @objc to a _member_ of a Swift-native class; this is what allows Swift-native classes to model @objc protocols and so on. But of course we don’t ever implicitly infer @objc on members of Swift-native classes just based on the calling convention of a method.
So now we could say that members of non-@objc classes only infer @objc if necessary to fulfill an override or protocol requirement, independently of whether the class is NSObject-derived or not; and @objc can now be applied to an entire class, as long as its NSObject-derived, to get the implicit inference behavior on members. Slava > On Mar 23, 2017, at 2:06 AM, Slava Pestov <[email protected]> wrote: > > Here’s an idea for working around the problem of the lack of static knowledge > during migration. Probably it’s kind of tacky and won’t get much traction in > it’s current form, but it might start some useful discussion at least. > > Right now, @objc when applied to a _class_ is completely useless; if a class > ultimately inherits from NSObject, it is always implicitly @objc, and > applying @objc to a class not rooted in NSObject is always an error. (I think > at some point in the past we allowed @objc classes that _don’t_ inherit from > NSObject, but I don’t know if that even made it into any released version of > Swift, so it’s totally vestigial at this point.) We can keep this behavior in > Swift 3 mode, but in Swift 4 mode, change things so that @objc applied to a > class enables @objc inference for the members of the class, and the absence > of @objc enables the new, more limited inference behavior outlined in this > proposal. > > Then the migration story can just be “slap @objc on every NSObject-derived > class and you’re good”. Existing mixed source bases, KVC, and so on would > just work. We could also say that in Swift 4 mode, @objc on an > NSObject-derived class produces a warning asking the developer to consider > making individual members @objc as necessary instead. This would allow a > Swift 4 migration to proceed in two phases — first fix any fallout from > SE-0110 or new string stuff or whatever, and get a working app that builds > and runs in Swift 4 mode, albeit with some warnings. Then they can deal with > marking individual class members as @objc later. We could still have the > option of making it an error to apply @objc to an entire class in a future > release of Swift, if we decide it is beneficial to do so. > > Based on feedback, the all-or-nothing nature of the Swift 2->3 migration was > rather painful — mixing and matching 3 and 4 modules will definitely help us > do better the next time around, and allowing a complex change such as this > one to be done piecemeal could be a further step in the right direction. > > Slava > >> On Mar 21, 2017, at 11:03 PM, Chris Lattner via swift-evolution >> <[email protected]> wrote: >> >> Hello Swift community, >> >> The review of "SE-0160: Limiting @objc inference" begins now and runs >> through March 28. The proposal is available here: >> >> >> https://github.com/apple/swift-evolution/blob/master/proposals/0160-objc-inference.md >> >> Reviews are an important part of the Swift evolution process. All reviews >> should be sent to the swift-evolution mailing list at: >> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> >> or, if you would like to keep your feedback private, directly to the review >> manager. >> >> >> What goes into a review? >> >> The goal of the review process is to improve the proposal under review >> through constructive criticism and, eventually, determine the direction of >> Swift. When writing your review, here are some questions you might want to >> answer in your review: >> >> * What is your evaluation of the proposal? >> * Is the problem being addressed significant enough to warrant a change to >> Swift? >> * Does this proposal fit well with the feel and direction of Swift? >> * If you have you used other languages or libraries with a similar feature, >> how do you feel that this proposal compares to those? >> * How much effort did you put into your review? A glance, a quick reading, >> or an in-depth study? >> >> More information about the Swift evolution process is available at: >> https://github.com/apple/swift-evolution/blob/master/process.md >> >> Thanks! >> >> -Chris Lattner >> Review Manager >> _______________________________________________ >> swift-evolution mailing list >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution > _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
