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

[Joe Groff]

> On Oct 19, 2016, at 10:53 AM, Douglas Gregor <dgregor at apple.com> wrote:
> 
>> 
>> On Oct 19, 2016, at 10:37 AM, Joe Groff <jgroff at apple.com <mailto:jgroff at apple.com>> wrote:
>> 
>>> 
>>> On Oct 19, 2016, at 9:35 AM, Douglas Gregor via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>> 
>>> 
>>>> On Oct 19, 2016, at 4:53 AM, Jay Abbott <jay at abbott.me.uk <mailto:jay at 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- at 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161019/17253d2c/attachment.html>