> 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
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
