> On May 31, 2017, at 2:02 PM, Stephen Celis <[email protected]> wrote:
>> 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.
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
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
