> On Mar 23, 2017, at 9:44 AM, Slava Pestov <[email protected]> wrote: > >> >> On Mar 22, 2017, at 10:34 PM, Charlie Monroe via swift-evolution >> <[email protected] <mailto:[email protected]>> wrote: >> >>> >>> On Mar 23, 2017, at 12:02 AM, Douglas Gregor via swift-evolution >>> <[email protected] <mailto:[email protected]>> wrote: >>> >>> >>>> On Mar 22, 2017, at 3:22 PM, Haravikk via swift-evolution >>>> <[email protected] <mailto:[email protected]>> wrote: >>>> >>>> >>>>> On 22 Mar 2017, at 06:03, Chris Lattner via swift-evolution >>>>> <[email protected] <mailto:[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 >>> >>> <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.
What about a symbol for a breakpoint? Like Auto Layout and many other frameworks (e.g. break on _NSErrorLog(), etc.) have... > > 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
