> On Mar 16, 2016, at 11:24 AM, Jordan Rose <[email protected]> wrote: > > >> On Mar 16, 2016, at 11:11, Joe Groff <[email protected] >> <mailto:[email protected]>> wrote: >> >> >>> On Mar 16, 2016, at 11:09 AM, Jordan Rose via swift-evolution >>> <[email protected] <mailto:[email protected]>> wrote: >>> >>> It's worth noting that—for better or for worse—explicit capture has >>> different semantics from implicit capture today. If a local variable >>> ('var', not 'let') is captured, it is captured by value when mentioned >>> explicitly and by reference when not. This is discussed in The Swift >>> Programming Language >>> <https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/Expressions.html#//apple_ref/doc/uid/TP40014097-CH32-ID544>. >>> >>> 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. >>> >>> (Not that I have an alternative spelling handy.) >> >> `[var x]` seems to me like a reasonable spelling for explicit `var` capture. > > 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".)
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. -Joe
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
