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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
