<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Thanks Ole,<div class=""><br class=""></div><div class="">You are perfectly right regarding the error message. For some reason, I misread it. I am sorry about that.</div><div class=""><br class=""></div><div class="">The actual error message, as you point out, makes much more sense!</div><div class=""><br class=""></div><div class="">The rest of your explanation makes sense too, except:</div><div class=""><br class=""></div><div class="">When I declare my closure as <span style="color: rgb(186, 45, 162); font-family: Menlo; font-size: 14px; font-variant-ligatures: no-common-ligatures;" class="">@noescape</span>, (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.</div><div class=""><br class=""></div><div class="">I would understand a warning, but I don’t understand that the compiler insists on putting out an error.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">Last, in presence of a similar warning (instead of an error), a simple way to squelch the warning would be to make the <span style="color: rgb(186, 45, 162); font-family: Menlo; font-size: 14px;" class="">@noescape</span> declaration explicit.</div><div class="">This would require un-deprecating it.</div><div class=""><br class=""></div><div class="">I now feel that I should propose that as an evolution.</div><div class=""><br class=""></div><div class="">What do you think?</div><div class=""><br class=""></div><div class="">Jean-Denis</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 10 Oct 2016, at 12:52, Ole Begemann <<a href="mailto:ole@oleb.net" class="">ole@oleb.net</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class=""><blockquote type="cite" class="">The line "let result = closure(n)" is refused by the compiler with the<br class="">error message "declaration over non closing parameter may allow it to<br class="">escape".<br class=""><br class="">First off, while I know what an escaping or a non-escaping closure is, I<br class="">find this error message utterly impossible to understand. To begin with,<br class="">the sentence "non closing parameter" is meaningless to me.<br class=""></blockquote><br class="">The error message I'm seeing in Xcode 8.0 is "Declaration closing over *non-escaping* parameter 'closure' may allow it to escape", so I don't know where you're seeing the "non closing parameter". And "non-escaping parameter" does make a lot more sense, I think.<br class=""><br class=""><blockquote type="cite" class="">In any case, my main function is passed a non-escaping closure. I want<br class="">to call it from inside it, the compiler is ok with. I want also to call<br class="">it from a nested function, but the compiler disagrees.<br class=""><br class="">I believe the compiler should not complain here. Did I miss anything?<br class=""></blockquote><br class="">I think the error message is actually quite good, given that the compiler apparently is taking some shortcuts to prove that a parameter doesn't escape.<br class=""><br class="">By declaring a function that closes over the non-escaping parameter, you're creating a situation that *may* allow the non-escaping closure to escape, i.e. the compiler can't guarantee anymore that it won't escape. For example, you could do assign the `closureDoubled` function to a variable that's outside the scope of `mainFunction`:<br class=""><br class=""> // Variable outside the scope of mainFunction<br class=""> var f: (Int) -> (Int) = { $0 }<br class=""><br class=""> func mainFunction(closure: (Int) -> Int) -> Int {<br class=""><br class=""> func closureDoubled(_ n: Int) -> Int {<br class=""> let result = closure(n)<br class=""> return 2*result<br class=""> }<br class=""><br class=""> // closure would escape here<br class=""> f = closureDoubled<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>...<br class=""> }<br class=""><br class=""> mainFunction { $0 }<br class=""> f(5)<br class=""><br class="">If this were allowed, `closure` would be able to escape. I think this possibility explains the error message.<br class=""><br class="">Now the compiler *could* of course check for this and I think you're right in arguing that it *should* ideally perform more sophisticated checks, but since it currently seems to be taking some shortcuts in guaranteeing that a parameter doesn't escape, it has to disallow anything it can't verify as correct.<br class=""><br class="">Ole<br class=""></div></div></blockquote></div><br class=""></div></body></html>