> On Jan 4, 2017, at 4:50 PM, Douglas Gregor via swift-evolution > <[email protected]> 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
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
