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.
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.
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
···
Sent from my iPhone
On Oct 18, 2016, at 4:00 PM, Jay Abbott via swift-evolution <swift-evolution@swift.org> wrote:
Ok, good to know that's just a bug. But I still think that implicit @objc
should be removed. 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'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.
···
On Wed, 19 Oct 2016 at 03:51 Douglas Gregor <dgregor@apple.com> wrote:
Sent from my iPhone
> On Oct 18, 2016, at 4:00 PM, Jay Abbott via swift-evolution < > 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.
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 Oct 19, 2016, at 4:53 AM, Jay Abbott <jay@abbott.me.uk> wrote:
On Wed, 19 Oct 2016 at 03:51 Douglas Gregor <dgregor@apple.com <mailto:dgregor@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.
It might also be nice if referring to a method with selector automatically tried to make it @objc.
-Joe
···
On Oct 19, 2016, at 9:35 AM, Douglas Gregor via swift-evolution <swift-evolution@swift.org> wrote:
On Oct 19, 2016, at 4:53 AM, Jay Abbott <jay@abbott.me.uk <mailto:jay@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 might, although I don’t love the impact on the implementation: we either end up creating one-off categories associated with the references to non-@objc methods or our type checker has to process function bodies to answer the question “is this method exposed to Objective-C”?
- Doug
···
On Oct 19, 2016, at 10:37 AM, Joe Groff <jgroff@apple.com> wrote:
On Oct 19, 2016, at 9:35 AM, Douglas Gregor via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
On Oct 19, 2016, at 4:53 AM, Jay Abbott <jay@abbott.me.uk <mailto:jay@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 might also be nice if referring to a method with selector automatically tried to make it @objc.
I don't think Sema necessarily needs to be involved. We could collect the full set of ObjC methods we need to emit for a class in a module and defer building a single category or class method table to IRGen time.
-Joe
···
On Oct 19, 2016, at 10:53 AM, Douglas Gregor <dgregor@apple.com> wrote:
On Oct 19, 2016, at 10:37 AM, Joe Groff <jgroff@apple.com <mailto:jgroff@apple.com>> wrote:
On Oct 19, 2016, at 9:35 AM, Douglas Gregor via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
On Oct 19, 2016, at 4:53 AM, Jay Abbott <jay@abbott.me.uk <mailto:jay@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 might also be nice if referring to a method with selector automatically tried to make it @objc.
It might, although I don’t love the impact on the implementation: we either end up creating one-off categories associated with the references to non-@objc methods or our type checker has to process function bodies to answer the question “is this method exposed to Objective-C”?
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 might also be nice if referring to a method with selector automatically tried to make it @objc.
How would this work? In all other cases it is clear that a method will become @objc at the declaration site. In this case it would not be.
···
On Oct 19, 2016, at 12:37 PM, Joe Groff via swift-evolution <swift-evolution@swift.org> wrote:
On Oct 19, 2016, at 9:35 AM, Douglas Gregor via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
On Oct 19, 2016, at 4:53 AM, Jay Abbott <jay@abbott.me.uk <mailto:jay@abbott.me.uk>> wrote:
If we move to this on-demand model for @objc-ness, then it seems to me we can potentially get away from @objc having to be a thing. The constraints on being representable in ObjC can still be enforced by the operation that demands an ObjC method, whether that be an attribute on the declaration itself or an operation that references the declaration.
-Joe
···
On Oct 19, 2016, at 11:24 AM, Matthew Johnson <matthew@anandabits.com> wrote:
On Oct 19, 2016, at 12:37 PM, Joe Groff via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
On Oct 19, 2016, at 9:35 AM, Douglas Gregor via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
On Oct 19, 2016, at 4:53 AM, Jay Abbott <jay@abbott.me.uk <mailto:jay@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 might also be nice if referring to a method with selector automatically tried to make it @objc.
How would this work? In all other cases it is clear that a method will become @objc at the declaration site. In this case it would not be.
Unless you’re making a library or a plugin or something that can’t completely know whether it’s being accessed by Objective-C clients.
Charles
···
On Oct 19, 2016, at 1:26 PM, Joe Groff via swift-evolution <swift-evolution@swift.org> wrote:
If we move to this on-demand model for @objc-ness, then it seems to me we can potentially get away from @objc having to be a thing. The constraints on being representable in ObjC can still be enforced by the operation that demands an ObjC method, whether that be an attribute on the declaration itself or an operation that references the declaration.