<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">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.<div class=""><br class=""></div><div class="">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.<br class=""><div class=""><br class=""></div><div class="">A.</div><div class=""><br class=""></div><div class=""><br class=""><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jan 5, 2016, at 11:32 AM, Douglas Gregor via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Hi all,<div class=""><br class=""></div><div class="">We currently have a bit of a surprise when one extends an @objc protocol:</div><div class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class=""><div class="">@objc protocol P { }</div></div><div class=""><div class=""><br class=""></div></div><div class=""><div class="">extension P {</div></div><div class=""><div class=""> func bar() { }</div></div><div class=""><div class="">}</div></div><div class=""><div class=""><br class=""></div></div><div class=""><div class="">class C : NSObject { }</div></div><div class=""><div class=""><br class=""></div></div><div class=""><div class="">let c = C()</div></div><div class=""><div class="">print(c.respondsToSelector("bar")) // prints "false"</div></div></blockquote><div class=""><br class=""></div><div class="">because the members of the extension are not exposed to the Objective-C runtime. </div><div class=""><br class=""></div><div class="">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. </div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>- Doug</div><div class=""><br class=""></div><div class="">[*] 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...</div>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=LRtxqIpN0uduUbaiFaLozLZv7i-2BSLNOBgkrlBNK2PSXva6RIsEJDVsSxFWmSi5vPM-2Fg19cgaOnKsUNxXeAwFTaFH5T4wj0ZPFOZU1XfXhWrbL4gduVdAbW61b3-2F80LgakV1-2FyzJY-2BRF5-2BVM8Mbf1yXn48pkGFOrm9KlJNWxi2YwrHNUxt1aiC5bTNDkAuQfeeealryxXegBEOJLqeGOSIU3qSERFxpMu2GCdCL0G8tY-3D" alt="" width="1" height="1" border="0" style="height:1px !important;width:1px !important;border-width:0 !important;margin-top:0 !important;margin-bottom:0 !important;margin-right:0 !important;margin-left:0 !important;padding-top:0 !important;padding-bottom:0 !important;padding-right:0 !important;padding-left:0 !important;" class="">
</div>
_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></div></div></div></body></html>