Ah, closures do get the same treatment here. Good point.
- Daniel Duan
On Mon, Apr 11, 2016 at 1:39 PM -0700, "Joe Groff" <jgr...@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
_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev
