> On Oct 19, 2016, at 4:53 AM, Jay Abbott <j...@abbott.me.uk> wrote:
>
> 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.
- Doug
>
>
>
> On Wed, 19 Oct 2016 at 03:51 Douglas Gregor <dgre...@apple.com
> <mailto:dgre...@apple.com>> wrote:
>
>
> Sent from my iPhone
>
> > On Oct 18, 2016, at 4:00 PM, Jay Abbott via swift-evolution
> > <swift-evolution@swift.org <mailto:swift-evolution@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
>
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
