<div dir="ltr">I created a draft proposal to make `@noescape` the default and created a new email thread with subject "[Proposal] Make non-escaping closures the default".<div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jun 2, 2016 at 1:22 AM, 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"><br><div><span><blockquote type="cite"><div>On Jun 1, 2016, at 9:22 PM, Trent Nadeau <<a href="mailto:tanadeau@gmail.com" target="_blank">tanadeau@gmail.com</a>> wrote:</div><br><div><div dir="ltr">I'd like to write this proposal.</div></div></blockquote><div><br></div></span>Go for it! Thanks,</div><div><br></div><div>-Chris</div><span><div><br><blockquote type="cite"><div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jun 2, 2016 at 12:11 AM, Chris Lattner via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On Jun 1, 2016, at 9:02 PM, Chris Lattner <<a href="mailto:clattner@apple.com" target="_blank">clattner@apple.com</a>> wrote:<br>
> 2) For noescape, the core team feels that the right solution is for closure arguments to *default* to noescape, which means that the attribute we should really need is @escaping.<br>
<br>
</span>To provide some more details, this approach has the following advantages:<br>
<br>
- Most functional algorithms written in pure Swift will benefit because they are naturally noescape. The core team feels that this will reduce the boilerplate involved with writing these algorithms.<br>
<br>
- The compiler has enough logic in it to provide a great QoI experience when a developer doesn’t think about escaping, and tries to escape a closure - it can provide a fixit that suggests adding @escaping.<br>
<br>
- Recent changes (to disallow escaping closures to close over an inout parameter) are pushing the language to prefer noescape closures. noescape closures have also always been the preferred default, since they eliminate a class of retain cycle issues.<br>
<br>
- "@autoclosure(escaping)" can be simplified and standardized to "@autoclosure @escaping”<br>
<br>
<br>
The two primary concerns with taking this direction were that it is would adversely impact resilience, and that imported Objective-C APIs would be too annoying to work with, because the compiler would have to be conservative and assume they are escaping:<br>
<br>
<br>
<br>
On resilience, the concern with this approach is that an API may not thinking about whether a closure parameter should be escaping or not, and this behavior makes it possible that someone could write “V1” of an API and not accidentally promise noescape semantics, but then need it in “V2” of the same API.<br>
<br>
John McCall pointed out that resilience in the type system is different than resilience in practice: An API changing to capture a closure and use it long after it was originally passed is likely to break the clients regardless of whether the type system captures this as an issue. He argues (and the argument is strong IMO) that it is *better* for resilient APIs to default to @noescape, since that forces the author of V2 to think about whether they are breaking their clients. If they are doing something that is “logically” noescape in their V2, then they can unsafe bitcast away the escaping aspect of the closure. This is better than changing the client’s view of the API in any case.<br>
<br>
<br>
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>
<br>
<br>
I’m happy to write up this proposal, but won’t have cycles to do so for several weeks. If someone else wants to take it up, that would be great :-)<br>
<span><font color="#888888"><br>
-Chris<br>
</font></span><div><div>_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div data-smartmail="gmail_signature">Trent Nadeau</div>
</div>
</div></blockquote></div><br></span></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div data-smartmail="gmail_signature">Trent Nadeau</div>
</div></div>