<html><head></head><body><div>Ah, closures do get the same treatment here. Good point.<br><br><div class="acompli_signature">- Daniel Duan</div><br></div><br><br><br>
<div class="gmail_quote">On Mon, Apr 11, 2016 at 1:39 PM -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 11, 2016, at 1:28 PM, Daniel Duan via swift-dev <swift-dev@swift.org> wrote:
>
>> Joe Groff via swift-dev <swift-dev <at> swift.org> writes:
>>
>> return local // returning forms a closure, so ref is escapable
>
> My plan was to check all return statements with FuncDecl as results, if
> any of them has inout captures, complain.
>
> But this diagnosis is too coarse. A function can capture from any level of
> outer scope, so sometimes it's safe to let a inout escape, as long as the
> reference is still inside the scope it's captured from. Example:
>
> func a(inout x: Int) -> () -> Void {
> func b() -> () -> Void {
> func c() {
> _ = x
> }
> return c // is this safe? We'll see…
> }
>
> let f = b() // 'x' captured by f hasn't *really* escaped.
>
> return f // now we have a problem
> }
>
> It's unclear whether the statement 'return c' is problematic.
>
> So there are two paths:
>
> 1. make *any* escaping inout capture an error
> 2. track down original scope of each inout capture, compare it with the return
> statement.
>
> At the moment I haven't looked into how feasible 2 is.
A local analysis is fine, and more predictable anyways. We already impose these constraints on @noescape parameters. If the local function reference appears as part of a function application or as a noescape argument, then treat the reference as noescape, otherwise consider it to escape.
-Joe</swift-dev></swift-dev@swift.org></pre>
</div>
</blockquote>
</div>
</body></html>