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

[David Waite]

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

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.

> * Is the problem being addressed significant enough to warrant a change to Swift?

Yes
> * Does this proposal fit well with the feel and direction of Swift?

I think so, other than the complexity issues
> * If you have you used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

I know of no other language with dispatch rules as complex as swift other than perhaps Objective-C++, which I haven’t used. I suspect in this small way the dispatch rules of Objective-C++ are simpler, because only message-dispatched members are allowed on the Objective-C classes and protocols (the C++ and Objective-C class systems are distinct)

> * How much effort did you put into your review? A glance, a quick reading, or an in-depth study? 

More than a quick reading, although I’ll admit I do not 100% understand the existing Swift rules of @objc and the effects of (for instance) declaring an @objc member on a non- at objc class.

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