[swift-evolution] Revisiting SE-0110

[Nate Cook]

> Joe Groff wrote:
> 
> Furthermore, this probably comes up most commonly with dictionaries, since they're a sequence of tuples. The element tuple for dictionaries has element labels (key: Key, value: Value), so instead of writing `{ tuple in let (key, value) = tuple; f(key, value) }`, you could use the implicit argument and write `{ f($0.key, $0.value) }`.

Dictionaries are definitely a common case for this, but zipped sequences and enumerated() sequences are also very common, and don't have labels attached.

Closures are so lightweight and permissive in what they accept that this change really does feel like a regression. I don't think the proposal accurately captured the impact of this change on code - that section only says "Minor changes to user code may be required if this proposal is accepted." Moreover, the examples given are all of standalone closures assigned to a constant rather than the far more prevalent inline usage in collection operations.

> Chris Lattner wrote: 
> 

> For consistency, the decision was to make closure parameter lists work the same way as function parameters. Function parameters do not allow destructuring of arguments in their declaration, so it seemed weird to let closures do that.

I have to say that for me, it has never seemed weird at the use site to destructure tuples like that. The only confusion I've ever seen from users is when deconstruction didn't work enough, like if the parameter was (Int, (Int, Int)) and you couldn't destructure the nested tuple.

Nate
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170525/1c885e9d/attachment.html>