<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="">
Sorry, your answer was perfectly fine. I’m the one who did a poor job acknowledging it :)
<div class=""><br class="">
</div>
<div class="">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 statically decidable. One simple (but maybe
too naïve?) solution might be to consider `f` as non-escaping as soon as there’s one path in the CFG where it’s assigned to an non-escaping closure. That way we could still disallow things like:</div>
<div class=""><br class="">
</div>
<div class=""><font face="Menlo" class="">let f = c ? nonEscParam : escParam</font></div>
<div class=""><font face="Menlo" class="">self.callback = f // <- assignment to possibly non-escaping closure</font></div>
<div class=""><br class="">
</div>
<div class="">But even so, the added complexity to the escape analysis is undeniable.</div>
<div class=""><br class="">
</div>
<div class="">Once again, thanks for your answer.</div>
<div class=""><br class="">
</div>
<div class="">Best,</div>
<div class="">Dimitri</div>
<div class=""><br class="">
<div class=""><br class="">
<div>
<blockquote type="cite" class="">
<div class="">On 31 May 2017, at 22:20, John McCall <<a href="mailto:rjmccall@apple.com" class="">rjmccall@apple.com</a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">
<div class="">
<blockquote type="cite" class="">
<div class="">On May 31, 2017, at 1:17 PM, Dimitri Racordon via swift-dev <<a href="mailto:swift-dev@swift.org" class="">swift-dev@swift.org</a>> wrote:</div>
<div class="">
<div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">
Thanks for your answer.
<div class=""><br class="">
</div>
<div class="">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 :)</div>
<div class=""><br class="">
</div>
<div class="">I was more wondering if there were situations where such local assignments would have to be disallowed.</div>
</div>
</div>
</blockquote>
<div class=""><br class="">
</div>
I was trying to answer that question; perhaps I did a poor job of explaining, and some examples would help.<br class="">
<div class=""><br class="">
</div>
<div class="">This should always be fine, and in principle we could allow it specifically:</div>
</div>
<div class=""> let function = someParameter</div>
<div class=""><br class="">
</div>
<div class="">This would probably also be okay:</div>
<div class=""> let function = { someClosure }</div>
<div class=""><br class="">
</div>
<div class="">This would be a problem:</div>
<div class=""> var function = someParameter</div>
<div class=""><br class="">
</div>
<div class="">As would this:</div>
<div class=""> let function = (someCondition ? someParameter : someOtherParameter)</div>
<div class=""><br class="">
</div>
<div class="">John.</div>
<div class=""><br class="">
<blockquote type="cite" class="">
<div class="">
<div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">
<div class=""><br class="">
</div>
<div class="">Best,</div>
<div class="">Dimitri</div>
<div class=""><br class="">
</div>
<div class="">
<div class=""><br class="">
<div class="">
<blockquote type="cite" class="">
<div class="">On 31 May 2017, at 22:10, John McCall <<a href="mailto:rjmccall@apple.com" class="">rjmccall@apple.com</a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">
<div class="">
<blockquote type="cite" class="">
<div class="">On May 31, 2017, at 12:21 PM, Dimitri Racordon via swift-dev <<a href="mailto:swift-dev@swift.org" class="">swift-dev@swift.org</a>> wrote:</div>
<div class="">
<div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">
Hi everyone,
<div class="">
<div class=""><br class="">
</div>
<div class="">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:</div>
<div class=""><br class="">
</div>
<div class="">
<div class=""><font face="Menlo" class="">func f(_ closure: () -> Int) {</font></div>
<div class=""><font face="Menlo" class=""> let a = closure</font></div>
<div class=""><font face="Menlo" class="">}</font></div>
</div>
<div class=""><br class="">
</div>
<div class="">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:</div>
<div class=""><br class="">
</div>
<div class="">
<div class=""><font face="Menlo" class="">var global = { 0 }</font></div>
<div class=""><font face="Menlo" class="">func f(_ closure: () -> Int) {</font></div>
<div class=""><font face="Menlo" class=""> global = closure</font></div>
<div class=""><font face="Menlo" class="">}</font></div>
</div>
<div class=""><br class="">
</div>
<div class="">But in my first example, since `a` is stack allocated, there’s no risk that `closure` escapes the scope of `f`.</div>
<div class=""><br class="">
</div>
<div class="">Is there some use case I’m missing, where such assignment could be problematic?</div>
<div class="">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?</div>
<div class=""><br class="">
</div>
</div>
<div class="">Thank you very much for your time and your answer.</div>
</div>
</div>
</blockquote>
<div class=""><br class="">
</div>
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.</div>
<div class=""><br class="">
</div>
<div class="">John.</div>
</div>
</div>
</blockquote>
</div>
<br class="">
</div>
</div>
</div>
_______________________________________________<br class="">
swift-dev mailing list<br class="">
<a href="mailto:swift-dev@swift.org" class="">swift-dev@swift.org</a><br class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-dev" class="">https://lists.swift.org/mailman/listinfo/swift-dev</a><br class="">
</div>
</blockquote>
</div>
<br class="">
</div>
</div>
</blockquote>
</div>
<br class="">
</div>
</div>
</body>
</html>