> On May 31, 2017, at 12:21 PM, Dimitri Racordon via swift-dev
> <swift-dev@swift.org> 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
> }
>
> I do understand that assigning a non-escaping closure to a variable whose
> lifetime exceeds that of the function would (by definition) violate the
> non-escaping property. For instance, doing that is understandably illegal:
>
> var global = { 0 }
> func f(_ closure: () -> Int) {
> global = closure
> }
>
> But in my first example, since `a` is stack allocated, there’s no risk that
> `closure` escapes the scope of `f`.
>
> Is there some use case I’m missing, where such assignment could be
> problematic?
> Or is this a limitation of the compiler, which wouldn't go all the way to
> check whether the lifetime of the assignee is compatible with that of the
> non-escaping parameter may exceed that of the variable it is assigned to?
>
> Thank you very much for your time and your answer.
Examples like yours, where a non-escaping closure parameter has a new constant
name bound to it, are supportable but rather pointless — as a programmer, why
have two names for the same value? Examples that would be more useful, like
assigning the closure into a local variable or allowing it to be used in a more
complex expression (like ? :), complicate the analysis for non-escaping
closures in a way that would significantly subvert their purpose.
John.
_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev
