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

[Douglas Gregor]

> 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.

	- Doug

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170331/650d8781/attachment.html>