Ok, good to know that's just a bug. But I still think that implicit @objc should be removed.
Oh, I agree that implicit @objc should be removed. I suspect it’s responsible for a nontrivial amount of code bloat and unnecessary Objective-C selector collisions.
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.
I don’t quite view explicit @objc as a cop-out—it’s a useful tool to limit the amount of glue code one needs to write.
I'm not really sure how this works though, at what level this is applied? Maybe it's more to do with the default build settings in Xcode than Swift itself? I just would rather see Swift stand alone by default.
I think it’s a Swift language change: we should only infer ‘@objc’ when the API
* Overrides of an @objc API,
* Satisfies a requirement of an @objc protocol, or
* Uses a Swift feature that requires the Objective-C runtime (e.g., @NSManaged, @IBAction, currently ‘dynamic’ although that feels wrong to me)
It’s hard to justify pushing for this in Swift 4 stage 1, because changing defaults doesn’t affect the ABI, but it’s something I’d love to see us do at some point in Swift 4.
On Oct 19, 2016, at 4:53 AM, Jay Abbott <firstname.lastname@example.org> wrote:
On Wed, 19 Oct 2016 at 03:51 Douglas Gregor <email@example.com <mailto:firstname.lastname@example.org>> wrote:
Sent from my iPhone
> On Oct 18, 2016, at 4:00 PM, Jay Abbott via swift-evolution <email@example.com <mailto:firstname.lastname@example.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.
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.