> On May 31, 2017, at 1:17 PM, Dimitri Racordon via swift-dev
> wrote:
> Thanks for your answer.
>
> I agree that it may not be the most useful feature (although I’m sure we
> could find not-so-contrived yet useful use-cases). Anyway, I guess that
> discussion would rather belong to the evolut
Sorry, your answer was perfectly fine. I’m the one who did a poor job
acknowledging it :)
I totally see how semantic analysis of such lifetimes may represent a complex
challenge. In fact, if I’m not mistaking, the “non-escapability” of `f` in `let
f = c ? nonEscParam : escParam` isn’t even stat
> On May 31, 2017, at 12:21 PM, Dimitri Racordon via swift-dev
> wrote:
> Hi everyone,
>
> I failed to find the reason why Swift does not allows a non-escaping
> parameter to be assigned to a local variable. Here is a minimal example:
>
> func f(_ closure: () -> Int) {
> let a = closure
>
Thanks for your answer.
I agree that it may not be the most useful feature (although I’m sure we could
find not-so-contrived yet useful use-cases). Anyway, I guess that discussion
would rather belong to the evolution list :)
I was more wondering if there were situations where such local assignm
Hi everyone,
I failed to find the reason why Swift does not allows a non-escaping parameter
to be assigned to a local variable. Here is a minimal example:
func f(_ closure: () -> Int) {
let a = closure
}
I do understand that assigning a non-escaping closure to a variable whose
lifetime exc
