<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Mar 23, 2017, at 9:03 AM, Charlie Monroe <<a href="mailto:charlie@charliemonroe.net" class="">charlie@charliemonroe.net</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><blockquote type="cite" class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px;"><div class=""><br class="Apple-interchange-newline">On Mar 23, 2017, at 9:44 AM, Slava Pestov <<a href="mailto:spestov@apple.com" class="">spestov@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="" style="font-family: Helvetica; font-size: 10px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><blockquote type="cite" class=""><div class=""><br class="Apple-interchange-newline">On Mar 22, 2017, at 10:34 PM, Charlie Monroe via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><blockquote type="cite" class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br class="Apple-interchange-newline">On Mar 23, 2017, at 12:02 AM, Douglas Gregor via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class=""><br class=""><blockquote type="cite" class="">On Mar 22, 2017, at 3:22 PM, Haravikk via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class=""><br class=""><blockquote type="cite" class="">On 22 Mar 2017, at 06:03, Chris Lattner via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class="">* What is your evaluation of the proposal?<br class=""></blockquote><br class="">In favour.<br class=""><br class="">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.<br class=""><br class="">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?<br class=""></blockquote><br class="">The source compatibility section of the proposal<br class=""><br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0160-objc-inference.md#source-compatibility" class="">https://github.com/apple/swift-evolution/blob/master/proposals/0160-objc-inference.md#source-compatibility</a><br class=""><br class="">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?<br class=""><br class="">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.<br class=""></blockquote><br class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><span class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;">I would very much like that, mostly for catching all scenarios with bindings on the Mac.</span><br class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><span class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;">Otherwise, I agree with the proposal, just am a bit concerned with some of my apps that heavily use bindings…</span></div></blockquote><div class=""><br class=""></div>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.</div></div></blockquote><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class=""></div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">What about a symbol for a breakpoint? Like Auto Layout and many other frameworks (e.g. break on _NSErrorLog(), etc.) have…</div></div></blockquote><br class=""></div><div>That’s a great idea! We could have the implicit @objc thunks call into _swift3ImplicitObjCEntrypoint (or similar).</div><div><br class=""></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>- Doug</div><div><br class=""></div><br class=""></body></html>