> On Mar 23, 2017, at 9:03 AM, Charlie Monroe <char...@charliemonroe.net> wrote: > >> >> On Mar 23, 2017, at 9:44 AM, Slava Pestov <spes...@apple.com >> <mailto:spes...@apple.com>> wrote: >> >>> >>> On Mar 22, 2017, at 10:34 PM, Charlie Monroe via swift-evolution >>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >>> >>>> >>>> On Mar 23, 2017, at 12:02 AM, Douglas Gregor via swift-evolution >>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >>>> >>>> >>>>> On Mar 22, 2017, at 3:22 PM, Haravikk via swift-evolution >>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >>>>> >>>>> >>>>>> On 22 Mar 2017, at 06:03, Chris Lattner via swift-evolution >>>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> 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…
That’s a great idea! We could have the implicit @objc thunks call into _swift3ImplicitObjCEntrypoint (or similar). - Doug
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution