[swift-evolution] Revisiting SE-0110

[Stephen Celis]

> 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