> On 16 Mar 2016, at 18:24, Jordan Rose via swift-evolution
> <[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".)
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.
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
