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

[Douglas Gregor]

> On Mar 23, 2017, at 2:06 AM, Slava Pestov via swift-evolution <swift-evolution at swift.org> 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.

I don’t think we should repurpose @objc to mean “infer @objc if possible”, but we could add a new attribute—you’d mentioned @objcMembers somewhere before, I’ll refer to it as @implicitobjc” here—that one could added to classes or extensions. The semantics could be:

* @implicitobjc added to a class implicitly makes members of that class *and all of its subclasses* @objc if they can be exposed to Objective-C
* @implicitobjc added to a class extension makes members of that class extension @objc if they can be exposed to Objective-C

This is a more elegant way to handle the XCTestCase issue—we can mark XCTestCase as @implicitobjc through some Clang-side attribute or API note—and makes it easy for class hierarchies that rely heavily on the Objective-C runtime to continue to get @objc inference.

	- Doug

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