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