What happens for people using @objc to choose the class's runtime name? It seems unfortunate to conflate that with changed inference.
Jordan > On Mar 23, 2017, at 02:11, Slava Pestov via swift-evolution > <[email protected]> wrote: > > 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 _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
