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