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

[Joe Groff]

> On Oct 19, 2016, at 11:24 AM, Matthew Johnson <matthew at anandabits.com> wrote:
> 
>> 
>> On Oct 19, 2016, at 12:37 PM, Joe Groff via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> 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.
> 
> 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

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