[swift-users] Compiler refuses non-escaping closure calls in nested function

[Ole Begemann]

> When I declare my closure as @noescape, (the default), I explicitly tell
> the compiler that, despite the fact closing over it *may* allow it to
> escape, I, the programmer, guarantee that it will not.
>
> I would understand a warning, but I don’t understand that the compiler
> insists on putting out an error.
>
> So, while the compiler could perhaps, as you say, perform more
> sophisticated checks, I don’t even request that. I request however, to
> be able to tell the compiler that I know better.
>
> If I am wrong, and if I still let the closure escape despite my promise,
> then I made a programming error, and my code can legitimately crash.

I wouldn't like this. I much prefer the current state where this is an 
error. That said, it would indeed be great if the compiler were smarter 
when it does the analysis whether a closure actually escapes.

There is already a bug report for this, by the way: SR-2274 [1]

[1]: https://bugs.swift.org/browse/SR-2274

> This is no different than using the “!” to promise the compiler that an
> optional is not nil: if I don’t keep my promise, the program crashes.
>
> Last, in presence of a similar warning (instead of an error), a simple
> way to squelch the warning would be to make the @noescape declaration
> explicit.
> This would require un-deprecating it.
>
> I now feel that I should propose that as an evolution.
>
> What do you think?

Again, I don't think we should go that route. I prefer the status quo.