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

[Jordan Rose]

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 <swift-evolution at swift.org> 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- at 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 <spestov at apple.com> 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 <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