<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=""><div class="">I'm against this for library evolution reasons: if someone releases a version of their library that has a non-escaping closure and later discovers it needs to be escaping, they can't change it.</div><div class=""><br class=""></div><div class="">IIRC the counterpoint to this is that people were probably implicitly relying on it being non-escaping already, and that there aren't many cases where you'd want to do this anyway. My counter-counterpoint is that you might have some case, like dispatch_async (er, DispatchQueue.async) with a semaphore where you <i class="">know</i> the closure isn't escaping, but you need to treat it as one. Maybe that just means we need an asUnsafeEscapingClosure helper in the standard library.</div><div class=""><br class=""></div><div class="">I also think it might be useful to be able to annotate <i class="">references</i> as non-escaping (purely for performance reasons), and I can't see those being non-escaping by default. I know we don't want to block one change because of something else that might happen down the line, but still.</div><div class=""><br class=""></div><div class="">Jordan</div><div class=""><br class=""></div><br class=""><div><blockquote type="cite" class=""><div class="">On Jun 5, 2016, at 20:49, Trent Nadeau 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=""><div dir="ltr" class=""><a href="https://github.com/tanadeau/swift-evolution/blob/make-noescape-default/proposals/XXXX-make-noescape-default.md" class="">https://github.com/tanadeau/swift-evolution/blob/make-noescape-default/proposals/XXXX-make-noescape-default.md</a><div class=""><br class=""></div><div class=""><div class=""># Make non-escaping closures the default</div><div class=""><br class=""></div><div class="">* Proposal: [SE-NNNN](NNNN-name.md)</div><div class="">* Author: [Trent Nadeau](<a href="https://github.com/tanadeau" class="">https://github.com/tanadeau</a>)</div><div class="">* Status: **Awaiting review**</div><div class="">* Review manager: TBD</div><div class=""><br class=""></div><div class="">## Introduction</div><div class=""><br class=""></div><div class="">The current default of closure arguments to functions (i.e., arguments to functions that themselves have function type such as `(T) -> U`) is to be "escaping", meaning they can escape the function body such as saving it to a field in a struct or a global variable. In order to say that a closure argument cannot possibly escape the function body ("non-escaping"), the developer must explicitly add an `@noescape` annotation to the argument type.</div><div class=""><br class=""></div><div class="">This proposal switches the default to be non-escaping and requires an `@escaping` annotation if a closure argument can escape the function body. Since the escaping case can be statically detected, this annotation can be added via an error with a fixit. Other annotations that have consequences for escape semantics (e.g., `@autoclosure(escaping)`) will be altered to make use of the new `@escaping` annotation.</div><div class=""><br class=""></div><div class="">Swift-evolution threads: [Discussion thread topic for that proposal (TBD)](<a href="http://news.gmane.org/gmane.comp.lang.swift.evolution" class="">http://news.gmane.org/gmane.comp.lang.swift.evolution</a>)</div><div class=""><br class=""></div><div class="">## Motivation</div><div class=""><br class=""></div><div class="">Per Chris Lattner [on swift-evolution](<a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160530/019880.html" class="">https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160530/019880.html</a>):</div><div class=""><br class=""></div><div class="">> To provide some more details, this approach has the following advantages:</div><div class="">></div><div class="">> - 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.</div><div class="">></div><div class="">> - 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.</div><div class="">></div><div class="">> - 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.</div><div class="">></div><div class="">> - "@autoclosure(escaping)" can be simplified and standardized to "@autoclosure @escaping”</div><div class=""><br class=""></div><div class="">## Detailed design</div><div class=""><br class=""></div><div class="">The `@noescape` annotation is removed from the language. The compiler will emit an error with a fixit to remove the annotation.</div><div class=""><br class=""></div><div class="">The compiler will emit an error if a closure argument is found to possibly escape the function body. In order to silence the warning, the developer must add, manually or via fixit, the `@escaping` annotation to the argument type.</div><div class=""><br class=""></div><div class="">The compiler's semantic analysis implementation can be simplified as the more constrained escaping case that conflicts with other attributes is now no longer the default.</div><div class=""><br class=""></div><div class="">The standard library should be changed to use the new default whenever possible by removing all uses of `@noescape` and only adding `@escaping` where the compiler detects the need.</div><div class=""><br class=""></div><div class="">### Imported C/Objective-C APIs</div><div class=""><br class=""></div><div class="">Per the Core Team, most Cocoa closure/block parameters are escaping (e.g., delegates). As such the Clang importer will automatically add the `@escaping` annotation to closure/block parameters encountered in imported Objective-C APIs unless they are explicitly marked with the Clang `((noescape))` attribute. This will also be done with imported C APIs with function pointer or block parameters.</div><div class=""><br class=""></div><div class="">## Impact on existing code</div><div class=""><br class=""></div><div class="">Existing code using the `@noescape` attribute will need to be migrated to remove the attribute since it will be the default. In addition, the compiler will need to detect escaping closures that are not marked with `@escaping` and create an error with a fixit to add the required attribute.</div><div class=""><br class=""></div><div class="">Uses of `@autoclosure(escaping)` must be changed to `@autoclosure @escaping`.</div><div class=""><br class=""></div><div class="">There should be few, if any, changes required for uses of Cocoa APIs as these will be mostly marked as `@escaping`, and escaping closure arguments are *more* constrained than non-escaping ones.</div><div class=""><br class=""></div><div class="">## Future directions</div><div class=""><br class=""></div><div class="">The `@noescape(once)` annotation proposed in [SE-0073](<a href="https://github.com/apple/swift-evolution/blob/master/proposals/0073-noescape-once.md" class="">https://github.com/apple/swift-evolution/blob/master/proposals/0073-noescape-once.md</a>) would, if some future version is accepted, just become `@once`.</div><div class=""><br class=""></div><div class="">## Alternatives considered</div><div class=""><br class=""></div><div class="">Leave the `@noescape` attribute and existing semantics as they are now.</div><div class=""><br class=""></div><div class="">## Acknowledgements</div><div class=""><br class=""></div><div class="">Thanks to Chris Lattner, **TBD**, and anyone else who reviewed and contributed to this proposal.</div><div class=""><br class=""></div><div class=""><br class=""></div>-- <br class=""><div class="gmail_signature" data-smartmail="gmail_signature">Trent Nadeau</div>
</div></div>
_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></body></html>