[swift-evolution] [Mini-proposal] Require @nonobjc on members of @objc protocol extensions
Félix Cloutier
felixcca at yahoo.ca
Tue Jan 5 11:15:22 CST 2016
Extensions on classes already work and I can't see them requiring @objc or @nonobjc. It's extensions on protocols that don't work from Objective-C. The way I understand it, Doug suggests a warning/error for extensions on @objc protocols, and a @nonobjc attribute to shut it up.
Your point may still stand if you use @objc protocols in your code.
Félix
> Le 5 janv. 2016 à 06:51:27, Andrey Tarantsov via swift-evolution <swift-evolution at swift.org> a écrit :
>
> I'm against this, because I often write extensions on Apple classes (like, say, UIColor) that are only intended to be used from Swift, in a pure-Swift project, and I need no stinking' @nonobjc in there.
>
> How much of a problem can this surprise be? You call a method, the compiler tells you it's not there, you look up the reason, no harm done.
>
> A.
>
>
>
>> On Jan 5, 2016, at 11:32 AM, Douglas Gregor via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>
>> Hi all,
>>
>> We currently have a bit of a surprise when one extends an @objc protocol:
>>
>> @objc protocol P { }
>>
>> extension P {
>> func bar() { }
>> }
>>
>> class C : NSObject { }
>>
>> let c = C()
>> print(c.respondsToSelector("bar")) // prints "false"
>>
>> because the members of the extension are not exposed to the Objective-C runtime.
>>
>> There is no direct way to implement Objective-C entry points for protocol extensions. One would effectively have to install a category on every Objective-C root class [*] with the default implementation or somehow intercept all of the operations that might involve that selector.
>>
>> Alternately, and more simply, we could require @nonobjc on members of @objc protocol extensions, as an explicit indicator that the member is not exposed to Objective-C. It’ll eliminate surprise and, should we ever find both the mechanism and motivation to make default implementations of @objc protocol extension members work, we could easily remove the restriction at that time.
>>
>> - Doug
>>
>> [*] Assuming you can enumerate them, although NSObject and the hidden SwiftObject cover the 99%. Even so, that it’s correct either, because the root class itself might default such a method, and the category version would conflict with it, so...
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160105/9c0c884d/attachment.html>
More information about the swift-evolution
mailing list