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.
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 know 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. I also think it might be useful to be able to annotate references 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. Jordan > On Jun 5, 2016, at 20:49, Trent Nadeau via swift-evolution > <[email protected]> wrote: > > https://github.com/tanadeau/swift-evolution/blob/make-noescape-default/proposals/XXXX-make-noescape-default.md > > <https://github.com/tanadeau/swift-evolution/blob/make-noescape-default/proposals/XXXX-make-noescape-default.md> > > # Make non-escaping closures the default > > * Proposal: [SE-NNNN](NNNN-name.md) > * Author: [Trent Nadeau](https://github.com/tanadeau > <https://github.com/tanadeau>) > * Status: **Awaiting review** > * Review manager: TBD > > ## Introduction > > 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. > > 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. > > Swift-evolution threads: [Discussion thread topic for that proposal > (TBD)](http://news.gmane.org/gmane.comp.lang.swift.evolution > <http://news.gmane.org/gmane.comp.lang.swift.evolution>) > > ## Motivation > > Per Chris Lattner [on > swift-evolution](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160530/019880.html > > <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160530/019880.html>): > > > To provide some more details, this approach has the following advantages: > > > > - 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. > > > > - 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. > > > > - 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. > > > > - "@autoclosure(escaping)" can be simplified and standardized to > > "@autoclosure @escaping” > > ## Detailed design > > The `@noescape` annotation is removed from the language. The compiler will > emit an error with a fixit to remove the annotation. > > 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. > > 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. > > 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. > > ### Imported C/Objective-C APIs > > 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. > > ## Impact on existing code > > 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. > > Uses of `@autoclosure(escaping)` must be changed to `@autoclosure @escaping`. > > 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. > > ## Future directions > > The `@noescape(once)` annotation proposed in > [SE-0073](https://github.com/apple/swift-evolution/blob/master/proposals/0073-noescape-once.md > > <https://github.com/apple/swift-evolution/blob/master/proposals/0073-noescape-once.md>) > would, if some future version is accepted, just become `@once`. > > ## Alternatives considered > > Leave the `@noescape` attribute and existing semantics as they are now. > > ## Acknowledgements > > Thanks to Chris Lattner, **TBD**, and anyone else who reviewed and > contributed to this proposal. > > > -- > Trent Nadeau > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
