[swift-evolution] [Review #2] SE-0160: Limiting @objc inference
dgregor at apple.com
Fri Mar 31 17:25:59 CDT 2017
> On Mar 31, 2017, at 11:32 AM, David Waite via swift-evolution <swift-evolution at swift.org> wrote:
>> https://github.com/apple/swift-evolution/blob/master/proposals/0160-objc-inference.md <https://github.com/apple/swift-evolution/blob/master/proposals/0160-objc-inference.md>
>> * What is your evaluation of the proposal?
> Mixed opinion.
> I feel the rules would be simpler if we either expected members to be objc or non-objc based on the parent type, not just overrides of the parent methods. I understand the space/performance optimization behind non-objc methods, but @objcMember and migration issues with key paths both would go away if @objc was just the default for members on an @objc class or Objective-C subclass.
That’s (almost) the model we have today, except…
> Inference that a member is not @objc solely by its signature should go away. If the context expects @objc members, an incorrect signature should be an error.
The effect of this is that a Swift class that derives NSObject would have to put “@nonobjc” on every method/property/etc. that uses Swift features that cannot be expressed in Objective-C. I don’t think that’s something we want.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution