<html><head></head><body><div>Great! I'll check return statements in addition to ApplyExpr arguments.<br><br><div class="acompli_signature">- Daniel Duan</div><br></div><br><br><br>
<div class="gmail_quote">On Mon, Apr 11, 2016 at 8:44 AM -0700, "Joe Groff" <span dir="ltr"><<a href="mailto:jgroff@apple.com" target="_blank">jgroff@apple.com</a>></span> wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="3D"ltr"">
<pre>
> On Apr 10, 2016, at 12:46 PM, Daniel Duan via swift-dev <swift-dev@swift.org> wrote:
>
> Hi all,
>
> I'm in the process of implementing SE-0035, which limits capturing inout
> parameter to @noescape contexts. The proposal is clear on capture behavior for
> the following:
>
> 1. closure literals
> 2. nested function passed as arguments.
>
> But I'm not sure what to do with this case, in which 'x' escapes.
>
> func captureAndEscape(inout x: Int) -> () -> Void { func foo()
> { _ = x } return foo }
>
> The most obvious answer is it should be considered with the same rule as
> a closure literal, but a nested function can not have @noescape in its type
> (for now anyways).
>
> So, should this be legal, then? If not, where/how should the error be?
Ideally IMO, we would consider a reference to a local function to be `@noescape` or not based on how the reference is used, rather than the type of the function declaration itself:
func escapes(_: () -> ())
func noescapes(_: @noescape () -> ())
func foo(inout x: Int) -> () -> () {
func local() { _ = x }
local() // full application doesn't form a closure, ref is @noescape here
noescapes(local) // parameter is noescape, so ref is noescape
escapes(local) // parameter is escapable, so ref is escapable
var x = local // assigning to var forms a closure, so ref is escapabale
return local // returning forms a closure, so ref is escapable
}
-Joe</swift-dev@swift.org></pre>
</div>
</blockquote>
</div>
</body></html>