[swift-evolution] [pitch] make @nonobjc the default

[Douglas Gregor]

Sent from my iPhone

> On Oct 18, 2016, at 4:00 PM, Jay Abbott via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 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't valid in obj-c and causes compile errors.

The operators bit is an outright bug, which I believe has already been fixed in master. 

> I'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.

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't generally have to think about it unless you're trying to use those declarations from Objective-C. 

> Thoughts?

I actually thought you were going further with this, eliminating the inferred @objc except in cases where it's needed to work with an existing framework. That's something I'd love to see someone working on.

  - Doug