> On Mar 22, 2017, at 10:34 PM, Charlie Monroe via swift-evolution > <[email protected]> wrote: > >> >> On Mar 23, 2017, at 12:02 AM, Douglas Gregor via swift-evolution >> <[email protected]> wrote: >> >> >>> 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. > > I would very much like that, mostly for catching all scenarios with bindings > on the Mac. > > Otherwise, I agree with the proposal, just am a bit concerned with some of my > apps that heavily use bindings…
Perhaps a better solution than NSLog would be if the existing code coverage support could be modified to instrument @objc thunks, but I don’t know the details well enough to say if this would be practical to implement in the Swift 4 time frame. Slava > >> >> - Doug >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] <mailto:[email protected]> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution> > > _______________________________________________ > swift-evolution mailing list > [email protected] <mailto:[email protected]> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
