<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 11:24 AM, Matthew Johnson <<a href="mailto:matthew@anandabits.com" class="">matthew@anandabits.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 12:37 PM, Joe Groff 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 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 class="">It might also be nice if referring to a method with #selector automatically tried to make it @objc.</div></div></div></blockquote><div class=""><br class=""></div>How would this work? In all other cases it is clear that a method will become @objc at the declaration site. In this case it would not be.</div></div></blockquote><br class=""></div><div>If we move to this on-demand model for @objc-ness, then it seems to me we can potentially get away from @objc having to be a thing. The constraints on being representable in ObjC can still be enforced by the operation that demands an ObjC method, whether that be an attribute on the declaration itself or an operation that references the declaration.</div><div><br class=""></div><div>-Joe</div><br class=""></body></html>