<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 Jun 1, 2016, at 11:29 PM, Jacob Bandes-Storch <<a href="mailto:jtbandes@gmail.com" class="">jtbandes@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote">On Wed, Jun 1, 2016 at 10:25 PM, Chris Lattner <span dir="ltr" class=""><<a href="mailto:clattner@apple.com" target="_blank" class="">clattner@apple.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><span class="">On Jun 1, 2016, at 9:28 PM, Jacob Bandes-Storch <<a href="mailto:jtbandes@gmail.com" target="_blank" class="">jtbandes@gmail.com</a>> wrote:<br class=""><div class=""><blockquote type="cite" class=""><br class=""><div class=""><div dir="ltr" class=""><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 class=""></blockquote><div class=""><br class=""></div><div class="">This part is what I proposed last year; still waiting on an update:</div><div class=""><br class=""></div><div class=""><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0012-add-noescape-to-public-library-api.md" target="_blank" class="">https://github.com/apple/swift-evolution/blob/master/proposals/0012-add-noescape-to-public-library-api.md</a></div><div class=""> </div></div></div></div></div></blockquote><br class=""></div></span><div class="">The problem with that proposal, and the reason it is sitting around in limbo is:</div><br class=""><div class="">1) it is prescriptive of a process “Audit system C/Objective-C libraries...", not a proposal for a set of specific changes.</div><div class=""><br class=""></div><div class="">2) swift-evolution isn’t the right place to propose changes for Foundation or other APIs outside of the standard library. </div><div class=""><br class=""></div><div class="">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></div></blockquote><div class=""><br class=""></div><div class="">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></div></div></div></blockquote></div><br class=""><div class="">At this point it is hard to say. All I know is that the only process for this is to discuss it on the list (in which case many Apple folk will probably notice and make take it up on their own volition) or by filing a bug with <a href="http://bugreporter.apple.com" class="">bugreporter.apple.com</a> requesting it. Neither of these approaches give you the transparency you seek into when or if it will happen.</div><div class=""><br class=""></div><div class="">I understand that this isn’t what you want to hear, but it’s just the reality that Apple’s general framework design and evolution is not governed by the swift-evolution process.</div><div class=""><br class=""></div><div class="">-Chris</div></body></html>