[swift-evolution] Revisiting SE-0110

[Anders Ha]

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 <swift-evolution at swift.org> 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
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution