> Le 24 mars 2017 à 09:10, Charlie Monroe <[email protected]> a écrit : > >> >> On Mar 24, 2017, at 8:20 AM, Jean-Daniel via swift-evolution >> <[email protected] <mailto:[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.
You’re right. I didn’t realize that it was only about implicit @obj method. Of course, the scope of that function is narrow enough that we don’t need to bother with the potential runtime cost.
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
