> On Mar 24, 2017, at 8:20 AM, Jean-Daniel via swift-evolution > <[email protected]> wrote: > >> >> Le 23 mars 2017 à 19:09, Douglas Gregor via swift-evolution >> <[email protected] <mailto:[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.
Correct me, if I'm wrong, but there will be no performance cost. This entry point would get called only from thunks that will go away in Swift 4 anyway and only in debug mode (possibly?). This way all @nonobjc calls within Swift are without the ObjC thunks (thus the entrypoint is not called), all explicitly @objc thunks are free of this entry point call and the only place this gets called is when your object gets a call from Objective-C code (runtime) to a thunk that is @objc implicitly and hence is going away in Swift 4 anyway and should be marked as @objc explicitly. This means: - 0 cost for production code - 0 cost for Swift-to-Swift calls (@nonobjc) - 0 cost for explicit @objc calls While DTrace is nice, I don't see the benefit of it here as you'd need to run it through Instruments instead of just setting a symbolic breakpoint in Xcode... Which seems way easier to use and eventually to debug. > > > _______________________________________________ > 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
