[swift-evolution] [Review] SE-0160: Limiting @objc inference

[Slava Pestov]

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 <swift-evolution at swift.org> 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
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution