> On Mar 22, 2017, at 3:22 PM, Haravikk via swift-evolution
> <[email protected]> wrote:
>
>
>> On 22 Mar 2017, at 06:03, Chris Lattner via swift-evolution
>> <[email protected]> wrote:
>> * What is your evaluation of the proposal?
>
> In favour.
>
> Like others I can foresee there being a bit of pain for some developers, but
> I think it's worth it to be more explicit about what's going on, and to clean
> up a feature that's just for supporting a specific other language.
>
> My main concern is on whether things could be made a bit easier; specifically
> I wonder whether we could introduce an option (to the compiler?) to trigger
> warnings anywhere there is a possible missing @objc attribute. Basically on
> any code that produces bridging headers this would give a warning anywhere
> that @objc would have been inferred in the past, but will no longer be. Of
> course this will generate a lot of warnings, but it'll be an easier way for
> developers to go through and make sure they didn't miss something. Xcode
> could offer this automatically during migration, and the developer can turn
> it off when they're done. Not perfect, but it may be a little extra help for
> those most affected?
The source compatibility section of the proposal
https://github.com/apple/swift-evolution/blob/master/proposals/0160-objc-inference.md#source-compatibility
describes the use of NS_DEPRECATED in the generated header for Swift 3
compatibility mode to get warnings on uses of entities that are implicitly
@objc but will no longer be in Swift 4. Does that address your concern?
I’ve also heard the idea of putting the same warnings into the generated
Objective-C thunks by NSLog’ing the same information as an opt-in,
pre-Swift-4-migration step to help catch the tricky cases where an Objective-C
entrypoint is getting called.
- Doug
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
