> On Mar 31, 2017, at 11:32 AM, David Waite via swift-evolution
> <[email protected]> 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
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
