[swift-dev] Help needed: SE-0035 design detail

[Daniel Duan]

Ah, closures do get the same treatment here. Good point.

- Daniel Duan




On Mon, Apr 11, 2016 at 1:39 PM -0700, "Joe Groff" <jgroff at apple.com> wrote:











> On Apr 11, 2016, at 1:28 PM, Daniel Duan via swift-dev  wrote:
> 
>> Joe Groff via swift-dev  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




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20160411/46a10297/attachment.html>