<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=""><br class=""><div><blockquote type="cite" class=""><div class="">On Mar 16, 2016, at 11:24 AM, Jordan Rose <<a href="mailto:jordan_rose@apple.com" class="">jordan_rose@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Mar 16, 2016, at 11:11, Joe Groff <<a href="mailto:jgroff@apple.com" class="">jgroff@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Mar 16, 2016, at 11:09 AM, Jordan Rose via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">It's worth noting that—for better or for worse—explicit capture has different semantics from implicit capture today. If a local <i class="">variable</i> ('var', not 'let') is captured, it is captured by value when mentioned explicitly and by reference when not. This is <a href="https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/Expressions.html#//apple_ref/doc/uid/TP40014097-CH32-ID544" class="">discussed in The Swift Programming Language</a>.</div><div class=""><br class=""></div><div class="">If you were to then propose a syntax of `inout x` or `&x`, I would argue that there is no inout-ish behavior: updates to the variable both inside and outside the closure (a) are always reflected immediately (i.e. there is no writeback), and (b) are not subject to the aliasing restrictions that 'inout' has. </div><div class=""><br class=""></div><div class="">(Not that I have an alternative spelling handy.)</div></div></div></blockquote><div class=""><br class=""></div><div class="">`[var x]` seems to me like a reasonable spelling for explicit `var` capture.</div></div></div></div></blockquote><br class=""></div><div class="">I forgot to preempt that one too. :-) That would be somewhat at odds with the "var x" we left in switches, which is definitely an independent variable. (Especially if someone extends it to "var x = y".)</div></div></div></blockquote><br class=""></div><div>OTOH it does more or less exactly what it says, capturing the `var` x rather than only the current value of x. It also makes some sense with the new restriction on capturing `inout` parameters—you can't capture an `inout x` using `var x` since you don't get to see the `var` through the inout abstraction. As far as `[var x = y]` is concerned, we could just say that's not allowed.</div><div><br class=""></div><div>-Joe</div><br class=""></body></html>