[swift-evolution] [Review #2] SE-0160: Limiting @objc inference
david at alkaline-solutions.com
Fri Mar 31 13:32:21 CDT 2017
> 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?
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?
> * 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution