[swift-evolution] Revisiting SE-0110

[John McCall]

> On May 31, 2017, at 2: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.

The consequences for point-free style were expected and cannot really be eliminated without substantially weakening SE-0110.  Closure convenience seems to me to be a much more serious regression.

John.


> 
>   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