[swift-evolution] [Mini-proposal] Require @nonobjc on members of @objc protocol extensions

[Douglas Gregor]

> On Jan 4, 2016, at 8:49 PM, Félix Cloutier <felixcca at yahoo.ca> wrote:
> 
> For the folks who don't mix Swift and Objective-C that much, extensions on @objc classes are exposed to the Objective-C runtime, so there is a discrepancy here. I'm not passionate about the outcome, just dropping the info.

Right. I think this is the reason that developers expect members of @objc protocol extensions to show up in Objective-C, because it automatically happens for extensions of @objc classes. (We’ve received a number of bug reports about this)

	- Doug

> 
> Félix
> 
>> Le 4 janv. 2016 à 23:32:25, Douglas Gregor via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> a écrit :
>> 
>> 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
> 

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