Sent from my iPhone
> On Oct 18, 2016, at 4:00 PM, Jay Abbott via swift-evolution
> <email@example.com> 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
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.
swift-evolution mailing list