[swift-evolution] [Proposal draft] Limiting @objc inference

[Douglas Gregor]

> On Jan 4, 2017, at 8:59 PM, Timothy Wood <tjw at me.com> wrote:
> 
> 
> 
> 
>> On Jan 4, 2017, at 4:50 PM, Douglas Gregor via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> 
> 
> 
>> A Swift 3-to-4 migrator is the hardest part of the story. Ideally, the migrator to only add @objc in places where it is needed, so that we see some of the expected benefits of code-size reduction. However, there are two problems with doing so:
>> 
>> Some of the uses that imply the need to add @objc come from Objective-C code, so a Swift 3-to-4 migrator would also need to compile the Objective-C code (possibly with a modified version of the Objective-C compiler) and match up the "deprecated" warnings mentioned in the Swift 3 compatibility mode bullet with Swift declarations.
>> 
>> The migrator can't reason about dynamically-constructed selectors or the behavior of other tools that might directly use the Objective-C runtime, so failing to add a @objc will lead to migrated programs that compile but fail to execute correctly.
>> 
> This seems fairly worrisome, but I’m sure how much so. I personally would probably prefer a guaranteed non-breaking migrator (since Swift 4 isn’t supposed to break stuff…) that adds the @objc where it was previously inferred. Sure, this won’t make existing code smaller/faster, but more importantly it won’t break it. The developer than then opt to remove the unneeded annotations over time (allowing for incremental testing and later bisection if a problem crops up).

It’s the conservative thing for the migrator to do, although it’ll potentially make a mess of migrated source code by littering it with potentially-unnecessary @objc’s.

>> Proposal add-on: @objc annotations on class definitions and extensions
>> 
>> If the annotation burden of @objc introduced by this proposal is too high, we could make @objc on a class definition or extension thereof imply @objc on those members that can be exposed to Objective-C. For example:
>> 
>> @objc extension MyClass {
>>   // implicitly @objc
>>   func f() { }
>> 
>>   // Cannot be exposed to Objective-C because tuples aren't representable in Objective-C
>>   func g() -> (Int, Int) { return (1, 2) }
>> }
> This seems like it goes counter to cleaning up the confusion by re-introducting silent non-exposure due to use of Swift-only types. It also seems odd that @objc would cascade to members when `public` and other access levels don’t (though it could do the same inference based on the access level of the types involved.

Yeah, I tend to agree with you that this add-on is likely not worth doing. I put it into the draft this way to provoke discussion, because this has come up before.

	- Doug


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