<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=""><blockquote type="cite" class="">On Oct 19, 2016, at 1:26 PM, Joe Groff via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""></blockquote><div><blockquote type="cite" class=""><br class="Apple-interchange-newline"><div class=""><span 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; float: none; display: inline !important;" class="">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.</span></div></blockquote></div><br class=""><div class="">Unless you’re making a library or a plugin or something that can’t completely know whether it’s being accessed by Objective-C clients.</div><div class=""><br class=""></div><div class="">Charles</div><div class=""><br class=""></div></body></html>