<div dir="ltr">@escaping would be part of the parameter type just as @noescape is today. Your foo(closure:) example wouldn&#39;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&#39;t be assigned to variables.<div><br></div><div>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&#39;t change.</div><div><br></div><div>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 &quot;escapiness&quot; as the protocol.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jun 7, 2016 at 3:45 AM, Brent Royal-Gordon <span dir="ltr">&lt;<a href="mailto:brent@architechies.com" target="_blank">brent@architechies.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">&gt; This proposal switches the default to be non-escaping and requires an `@escaping` annotation if a closure argument can escape the function body.<br>
<br>
</span>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:<br>
<br>
        func foo(closure: () -&gt; Void) {<br>
                let bar = closure       // You should not be able to escape through `bar`<br>
        }<br>
<br>
But then there are also many places where you would have to write @escaping even though a non-escaping closure would be obviously nonsensical:<br>
<br>
        struct Foo {<br>
                var closure: () -&gt; Void                 // Error; @escaping is mandatory here<br>
                func method() -&gt; () -&gt; Void {...}       // Same<br>
        }<br>
<br>
Requiring a boilerplate attribute like this is not really so great.<br>
<span class=""><br>
&gt; 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.<br>
<br>
</span>This becomes difficult when a protocol has a closure parameter; there&#39;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.<br>
<br>
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.<br>
<br>
(By the way, is an @escaping closure a subtype of a non-escaping closure?)<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Brent Royal-Gordon<br>
Architechies<br>
<br>
</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">Trent Nadeau</div>
</div>