<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 12:30 PM, Haravikk <<a href="mailto:swift-evolution@haravikk.me" class="">swift-evolution@haravikk.me</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><blockquote type="cite" class=""><div class=""><br class="Apple-interchange-newline">On 16 Mar 2016, at 18:24, 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=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><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=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><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=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class="">It's worth noting that—for better or for worse—explicit capture has different semantics from implicit capture today. If a local<span class="Apple-converted-space"> </span><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></div><br class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">What about “capture” as the keyword? This will require a new name for capture lists, but it seems like it isn’t well named at the moment anyway if it’s effectively copying values right now.</div><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br class=""></div><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">I’m also curious about thoughts regarding making implicit capture opt-in by default, vs the original proposals opt-out solution. Obviously this will require a good solution to the capture lists to replace the functionality and/or an attribute to opt-in to the current implicit behaviour, but I think it’s safer for it to be opt-in rather than the default.</div></div></blockquote></div><br class=""><div class="">I suspect that by far the most common use for capture lists is to declare [(weak|unowned) self]. I don't think we want to punish that use case.</div><div class=""><br class=""></div><div class="">-Joe</div></body></html>