>
> 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-@objc class.
-DW
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
