We could spell the new attribute @objcMembers or something like that. Slava
> On Mar 23, 2017, at 10:03 AM, Jordan Rose <jordan_r...@apple.com> wrote: > > 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@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-@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 <spes...@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@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@swift.org >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> >> >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org >> https://lists.swift.org/mailman/listinfo/swift-evolution > _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
