[swift-evolution] [Proposal] Make non-escaping closures the default

[Trent Nadeau]

@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 <brent at architechies.com>
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- at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160607/d2403c4e/attachment.html>