Re: [swift-evolution] [pitch] make @nonobjc the default

[Joe Groff via swift-evolution]

> On Oct 19, 2016, at 11:24 AM, Matthew Johnson  wrote:
> 
>> 
>> On Oct 19, 2016, at 12:37 PM, Joe Groff via swift-evolution 
>> > wrote:
>> 
>> 
>>> On Oct 19, 2016, at 9:35 AM, Douglas Gregor via swift-evolution 
>>> > wrote:
>>> 
>>> 
 On Oct 19, 2016, at 4:53 AM, Jay Abbott > 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.

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

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [pitch] make @nonobjc the default

[Charles Srstka via swift-evolution]

> On Oct 19, 2016, at 1:26 PM, Joe Groff via swift-evolution 
>  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.

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

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [pitch] make @nonobjc the default

[Matthew Johnson via swift-evolution]

> On Oct 19, 2016, at 12:37 PM, Joe Groff via swift-evolution 
>  wrote:
> 
> 
>> On Oct 19, 2016, at 9:35 AM, Douglas Gregor via swift-evolution 
>> > wrote:
>> 
>> 
>>> On Oct 19, 2016, at 4:53 AM, Jay Abbott >> > 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.

> 
> -Joe
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [pitch] make @nonobjc the default

[Joe Groff via swift-evolution]

> On Oct 19, 2016, at 10:53 AM, Douglas Gregor  wrote:
> 
>> 
>> On Oct 19, 2016, at 10:37 AM, Joe Groff > > wrote:
>> 
>>> 
>>> On Oct 19, 2016, at 9:35 AM, Douglas Gregor via swift-evolution 
>>> > wrote:
>>> 
>>> 
 On Oct 19, 2016, at 4:53 AM, Jay Abbott > 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”?

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

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [pitch] make @nonobjc the default

[Joe Groff via swift-evolution]

> On Oct 19, 2016, at 9:35 AM, Douglas Gregor via swift-evolution 
>  wrote:
> 
> 
>> On Oct 19, 2016, at 4:53 AM, Jay Abbott > > 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.

-Joe

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [pitch] make @nonobjc the default

[Douglas Gregor via swift-evolution]

> On Oct 19, 2016, at 4:53 AM, Jay Abbott  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  > wrote:
> 
> 
> 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 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

Re: [swift-evolution] [pitch] make @nonobjc the default

[Jay Abbott via swift-evolution]

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  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.
>
>   - Doug
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [pitch] make @nonobjc the default

[Douglas Gregor via swift-evolution]

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 
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