It is also fairly common not only with stdlib collection types, but also async
programming libraries like RxSwift and ReactiveSwift. Given n discrete time
sequence with values of type X1, X2, ... and Xn respectively, these may combine
or zip the sequences into a sequence of value type `(X1, X2, …, Xn)`. Then the
resulting sequence is observed with a closure `((X1, X2, …, Xn)) -> Void`,
written as `{ x1, x2, …, xn in arbitraryWork() }`.
This could be a considerable regression for these libraries specifically, since
Swift doesn’t seem getting variadic generics in the near future. A notable side
effect would be losing return type inference on all these use cases, since the
closure is now forced to be multi-line if one wants named tuple members.
> On 25 May 2017, at 11:47 PM, Nate Cook via swift-evolution
> <[email protected]> wrote:
>
>> 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
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
