[swift-evolution] [Pitch] Limit Implicit Capture

[Joe Groff]

> On Mar 16, 2016, at 12:30 PM, Haravikk <swift-evolution at haravikk.me> wrote:
> 
>> 
>> On 16 Mar 2016, at 18:24, Jordan Rose via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> 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".)
> 
> 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.
> 
> 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.

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.

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