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

[Timothy Wood]

> On Jan 4, 2017, at 4:50 PM, Douglas Gregor via swift-evolution <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).

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

Overall this looks pretty appealing!

-tim

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