<div dir="ltr"><div>Ok, good to know that&#39;s just a bug. But I still think that implicit @objc should be removed. 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><br></div>I&#39;m not really sure how this works though, at what level this is applied? Maybe it&#39;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><div><br><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, 19 Oct 2016 at 03:51 Douglas Gregor &lt;<a href="mailto:dgregor@apple.com">dgregor@apple.com</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br class="gmail_msg">
<br class="gmail_msg">
Sent from my iPhone<br class="gmail_msg">
<br class="gmail_msg">
&gt; On Oct 18, 2016, at 4:00 PM, Jay Abbott via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>&gt; wrote:<br class="gmail_msg">
&gt;<br class="gmail_msg">
&gt; Currently, if you extend a class that comes from obj-c, Swift assumes you want to make those methods available to call from obj-c code. If you add operators, you must declare them as @nonobjc otherwise the bridging header which is generated declares obj-c methods with the operator character as the method name, which isn&#39;t valid in obj-c and causes compile errors.<br class="gmail_msg">
<br class="gmail_msg">
The operators bit is an outright bug, which I believe has already been fixed in master.<br class="gmail_msg">
<br class="gmail_msg">
&gt; I&#39;m just wondering how others feel about this - my feeling is that a Swift developer should not have to know anything about obj-c when doing Swifty things to a bridged class from a framework (such as extending it). As far as they are concerned the framework class should compile the same as if it were fully implemented in Swift.<br class="gmail_msg">
<br class="gmail_msg">
Modulo bugs like the above, I think we already have this property? Swift declarations are exposed to Objective-C if they can be. One doesn&#39;t generally have to think about it unless you&#39;re trying to use those declarations from Objective-C.<br class="gmail_msg">
<br class="gmail_msg">
&gt; Thoughts?<br class="gmail_msg">
<br class="gmail_msg">
I actually thought you were going further with this, eliminating the inferred @objc except in cases where it&#39;s needed to work with an existing framework. That&#39;s something I&#39;d love to see someone working on.<br class="gmail_msg">
<br class="gmail_msg">
  - Doug<br class="gmail_msg">
<br class="gmail_msg">
</blockquote></div>