> Le 23 mars 2017 à 19:09, Douglas Gregor via swift-evolution > <[email protected]> a écrit : > >> >> On Mar 23, 2017, at 9:03 AM, Charlie Monroe <[email protected] >> <mailto:[email protected]>> wrote: >> >>> >>> On Mar 23, 2017, at 9:44 AM, Slava Pestov <[email protected] >>> <mailto:[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… > > That’s a great idea! We could have the implicit @objc thunks call into > _swift3ImplicitObjCEntrypoint (or similar).
What about using dtrace to reduce the performance cost of such feature ? This is exactly what is was design for. Being able to trace a program when needed without paying for it when not necessary.
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
