<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 Oct 19, 2016, at 10:37 AM, Joe Groff <<a href="mailto:jgroff@apple.com" class="">jgroff@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><blockquote type="cite" class=""><div class=""><br class="Apple-interchange-newline">On Oct 19, 2016, at 9:35 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=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Oct 19, 2016, at 4:53 AM, Jay Abbott <<a href="mailto:jay@abbott.me.uk" class="">jay@abbott.me.uk</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="">Ok, good to know that's just a bug. But I still think that implicit @objc should be removed.<span class="Apple-converted-space"> </span></div></div></div></blockquote><div class=""><br class=""></div><div class="">Oh, I agree that implicit @objc should be removed. I suspect it’s responsible for a nontrivial amount of code bloat and unnecessary Objective-C selector collisions.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="">For bridged classes with obj-c-specific interfaces (for example a method that takes a selector), it would be better if the Swift-side interface was forced to make a Swifty interface that hides it. This way, the people maintaining an interface have to either a) write a wrapper with a Swifty interface; or b) explicitly cop out and use @objc and inform their users that they may also have to do the same in some situations; or c) persuade their employers to let them port the whole thing to pure Swift, which sounds like a lot of fun and is probably what they really want to do :D.<br class=""></div></div></div></blockquote><div class=""><br class=""></div><div class="">I don’t quite view explicit @objc as a cop-out—it’s a useful tool to limit the amount of glue code one needs to write.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class="">I'm not really sure how this works though, at what level this is applied? Maybe it's more to do with the default build settings in Xcode than Swift itself? I just would rather see Swift stand alone by default.<br class=""></div></div></blockquote><div class=""><br class=""></div><div class="">I think it’s a Swift language change: we should only infer ‘@objc’ when the API</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>* Overrides of an @objc API,</div><div class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>* Satisfies a requirement of an @objc protocol, or</div><div class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>* Uses a Swift feature that requires the Objective-C runtime (e.g., @NSManaged, @IBAction, currently ‘dynamic’ although that feels wrong to me)</div></div></div></div></blockquote><br class=""></div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">It might also be nice if referring to a method with #selector automatically tried to make it @objc.</div></div></blockquote><br class=""></div><div>It might, although I don’t love the impact on the implementation: we either end up creating one-off categories associated with the references to non-@objc methods or our type checker has to process function bodies to answer the question “is this method exposed to Objective-C”?</div><div><br class=""></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>- Doug</div><div><br class=""></div><br class=""></body></html>