Sent from my iPhone

> On Oct 18, 2016, at 4:00 PM, Jay Abbott via swift-evolution 
> <> 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 

> 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 

> 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

swift-evolution mailing list

Reply via email to