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