@escaping would be part of the parameter type just as @noescape is today. Your foo(closure:) example wouldn't compile with my proposal, the same as today if you marked the parameter with @noescape. Non-escaping function parameters are only allowed to be called. They can't be assigned to variables.
The current @noescape and the proposed @escaping can only be applied to the types of function parameters so the code in your `struct Foo` example wouldn't change. Currently escaping and non-escaping closures are considered to be different types so there is already a problem when a protocol requires a function with a closure parameter. All conforming types must use the same "escapiness" as the protocol. On Tue, Jun 7, 2016 at 3:45 AM, Brent Royal-Gordon <[email protected]> wrote: > > This proposal switches the default to be non-escaping and requires an > `@escaping` annotation if a closure argument can escape the function body. > > Is @escaping part of the function type syntax (like @autoclosure) or the > parameter syntax (like inout)? It seems to me that there are places where > you *do* want non-parameter closure variables to be non-escaping: > > func foo(closure: () -> Void) { > let bar = closure // You should not be able to > escape through `bar` > } > > But then there are also many places where you would have to write > @escaping even though a non-escaping closure would be obviously nonsensical: > > struct Foo { > var closure: () -> Void // Error; > @escaping is mandatory here > func method() -> () -> Void {...} // Same > } > > Requiring a boilerplate attribute like this is not really so great. > > > 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. > > This becomes difficult when a protocol has a closure parameter; there's > not necessarily a default implementation to examine for escaping, and even > if there is one, the default may be a simple, non-escaping implementation > for something which ought to allow escaping from other implementations. > Similar concerns apply to non-final class members. > > One way to address this issue would be to have the migrator conservatively > mark non-@noescape closure parameters in protocol and class definitions > as @escaping, but that might undermine the intent of automatically > transitioning a lot of code to the new default. > > (By the way, is an @escaping closure a subtype of a non-escaping closure?) > > -- > Brent Royal-Gordon > Architechies > > -- Trent Nadeau
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
