[swift-evolution] Revisiting SE-0110

[Robert Bennett]

Seeing this makes me rethink the severity of this problem. I wonder if it would be worth it to add a starMap function that works like map, but unpacks tuples into separate arguments. So dict.map { (key, value) in ... } is still illegal but dict.starMap { (key, value) in ... } works like dict.map used to.

On May 31, 2017, at 5:02 PM, Stephen Celis <stephen.celis at gmail.com> wrote:

>> On May 28, 2017, at 7:04 PM, John McCall via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> Yes, I agree.  We need to add back tuple destructuring in closure parameter lists because this is a serious usability regression.  If we're reluctant to just "do the right thing" to handle the ambiguity of (a,b), we should at least allow it via unambiguous syntax like ((a,b)).  I do think that we should just "do the right thing", however, with my biggest concern being whether there's any reasonable way to achieve that in 4.0.
> 
> Closure parameter lists are unfortunately only half of the equation here. This change also regresses the usability of point-free expression.
> 
>   func add(_ x: Int, _ y: Int) -> Int {
>     return x + y
>   }
> 
>   zip([1, 2, 3], [4, 5, 6]).map(add)
> 
>   // error: nested tuple parameter '(Int, Int)' of function '(((_.Element, _.Element)) throws -> _) throws -> [_]' does not support destructuring
> 
> This may not be a common pattern in most projects, but we heavily use this style in the Kickstarter app in our functional and FRP code. Definitely not the most common coding pattern, but a very expressive one that we rely on.
> 
> Our interim solution is a bunch of overloaded helpers, e.g.:
> 
>   func tupleUp<A, B, C>(_ f: (A, B) -> C) -> ((A, B)) -> C {
>     return 
>   }
> 
>   zip([1, 2, 3], [4, 5, 6]).map(tupleUp(add))
> 
> Stephen