[swift-evolution] [Pitch] Limit Implicit Capture

[Joe Groff]

> On Mar 16, 2016, at 11:24 AM, Jordan Rose <jordan_rose at apple.com> wrote:
> 
> 
>> On Mar 16, 2016, at 11:11, Joe Groff <jgroff at apple.com <mailto:jgroff at apple.com>> wrote:
>> 
>> 
>>> On Mar 16, 2016, at 11:09 AM, Jordan Rose via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160316/49e537e0/attachment.html>