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