<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 5, 2016, at 3:51 AM, Andrey Tarantsov &lt;<a href="mailto:andrey@tarantsov.com" class="">andrey@tarantsov.com</a>&gt; 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="">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></div></blockquote><div><br class=""></div><div>You are misreading my proposal. I’m not proposing to change anything about how extensions of classes work. Your extensions of UIColor and other Objective-C classes remain unchanged.</div><div><br class=""></div><div>How many Apple *protocols*, such as delegates, have you extended? I expect it’s not that many.</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=""><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></div></div></blockquote><div><br class=""></div><div>I’ve seen enough bugs filed and general confusion about this that the answer is “it’s quite a bit of a surprise”. The common case seems to be that people write a protocol extension of a delegate that implements some of its optional members. The only calls to that method occur in some framework code written in Objective-C, so there place for the compiler to tell you it’s not there.</div><div><br class=""></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=""><div class=""><div class=""><br class=""></div><div class="">A.</div><div class=""><br class=""></div><div class=""><br class=""><div class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Jan 5, 2016, at 11:32 AM, Douglas Gregor via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; 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="">&nbsp; 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.&nbsp;</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.&nbsp;</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=""><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></div></div></div></blockquote></div><br class=""></body></html>