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

Douglas Gregor dgregor at apple.com
Mon Jan 4 22:32:25 CST 2016

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...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160104/13c3d184/attachment.html>

More information about the swift-evolution mailing list