> On May 28, 2017, at 7:04 PM, John McCall via swift-evolution
> <[email protected]> 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
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
