<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=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jan 4, 2016, at 8:49 PM, Félix Cloutier <<a href="mailto:felixcca@yahoo.ca" class="">felixcca@yahoo.ca</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=""><div class="">For the folks who don't mix Swift and Objective-C that much, extensions on @objc classes are exposed to the Objective-C runtime, so there is a discrepancy here. I'm not passionate about the outcome, just dropping the info.</div></div></div></blockquote><div><br class=""></div>Right. I think this is the reason that developers expect members of @objc protocol extensions to show up in Objective-C, because it automatically happens for extensions of @objc classes. (We’ve received a number of bug reports about this)</div><div><br class=""></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>- Doug</div><div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div class="">
<span class="Apple-style-span" style="border-collapse: separate; line-height: normal; border-spacing: 0px;">Félix</span>
</div>
<br class=""><div class=""><blockquote type="cite" class=""><div class="">Le 4 janv. 2016 à 23:32:25, Douglas Gregor via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> a écrit :</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=iRI3beHTe3UxYAHTlV3lA38zIPfHMhyuRzgTmGKV6k4g5krDa9XbwfoN1UpeKiY9ODX-2BJK0IH2B67bBlyoHB-2FUzl2PqDa8oWvX6SAEs-2BczYF6nqwoXaqp43meMjCu-2BPg01UjW5QAgGcudA7ylp0UgjlV8gY4CL2KFasxLTTVWpPuw-2B0cWpTGKK0jPreZAry4XclgXrbpmgCFQfGr-2F2IkZw-3D-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=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class=""></div></div></blockquote></div><br class=""></body></html>