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

[Jean-Denis Muys]

So I suppose you feel this case is different from the (unsafe)  implicitly unwrapping of optionals with the “!” operator.

Why do you feel the situation is different?


> On 10 Oct 2016, at 17:34, Ole Begemann <ole at oleb.net> wrote:
> 
>> 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.
>