<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Jun 1, 2016 at 10:25 PM, Chris Lattner <span dir="ltr"><<a href="mailto:clattner@apple.com" target="_blank">clattner@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><span class="">On Jun 1, 2016, at 9:28 PM, Jacob Bandes-Storch <<a href="mailto:jtbandes@gmail.com" target="_blank">jtbandes@gmail.com</a>> wrote:<br><div><blockquote type="cite"><br><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
On imported Objective-C API, the core team did a quick study of the Cocoa APIs and found that most closure/block parameters are escaping in practice. As such, the core team feels that it isn’t overly burdensome to ask that imported Objective-C APIs annotate their semantically noescape block parameters with the clang __attribute__((noescape)) attribute.<br></blockquote><div><br></div><div>This part is what I proposed last year; still waiting on an update:</div><div><br></div><div><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0012-add-noescape-to-public-library-api.md" target="_blank">https://github.com/apple/swift-evolution/blob/master/proposals/0012-add-noescape-to-public-library-api.md</a></div><div> </div></div></div></div></div></blockquote><br></div></span><div>The problem with that proposal, and the reason it is sitting around in limbo is:</div><br><div>1) it is prescriptive of a process “Audit system C/Objective-C libraries...", not a proposal for a set of specific changes.</div><div><br></div><div>2) swift-evolution isn’t the right place to propose changes for Foundation or other APIs outside of the standard library. </div><div><br></div><div>It has been stuck in a crack for a long time, and has no hope of getting unstuck. I think that at this point the right thing is to close it. Is that ok with you?</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>-Chris</div></font></span></div></blockquote><div><br></div><div>Okay, but is there any other way the community can have input on the set of functions/methods that should be updated, and some visibility into whether/when this will happen? It was my impression that Philippe was making progress on this, but I hadn't heard any more for a while. (My concern would be APIs getting missed due to lack of community input.)</div></div><br></div></div>