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 > <[email protected]> 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 > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
