[swift-evolution] Revisiting SE-0110

[Robert Bennett]

The word you're looking for is inconvenient 😁

If we allow dropping parentheses for tuples then we should disallow the outer parentheses to avoid ambiguity between multi-argument closures and closures taking a single tuple as their argument. Then, a closure taking multiple arguments would have to be written as "x, y in" and a closure taking a tuple as "(x, y) in". I'm ok with this too. I just want to make sure whatever solution we come up with adheres to the goal of SE-0110, which is to clearly separate functions taking multiple arguments from functions taking a tuple. For clarity, whatever solution we come up with should wrap the arguments within a tuple in an extra pair of parentheses. So for a multi-argument and single-tuple closure, respectively, either "x, y in" and "(x, y) in", or "(x, y) in" and "((x, y)) in".

> On May 29, 2017, at 1:32 PM, Vladimir.S via swift-evolution <swift-evolution at swift.org> wrote:
> 
>> On 29.05.2017 18:26, Nevin Brackett-Rozinsky via swift-evolution wrote:
>> On Sun, May 28, 2017 at 7:04 PM, John McCall via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>    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.
>>    John.
>> I agree with John, the best thing for actually using Swift is to allow tuple destructuring here, and the outermost parentheses (around the entire parameter list of a closure) should continue to be optional. Requiring double-parens would seem unnecessarily and arbitrarily…whatever the opposite of “convenient” is.
>> Nevin
> 
> If I understand correctly, correct me if I'm wrong, after *full* implementation of SE-0066, the function with two parameters should have different type than function with one tuple parameter:
> 
> I.e.
> typealias FuncParams = (Int, Int)->()
> typealias FuncTuple = ((Int, Int))->()
> 
> print(FuncParams.self) // should be (Int, Int)->()
> print(FuncTuple.self) // should be ((Int, Int))->()
> 
> So, if we have
> 
> func barParams(_ f: FuncParams) {
>    f(1,2)
> }
> 
> func barTuple(_ f: FuncTuple) {
>    f((1,2))
> }
> 
> and
> 
> func fooWithParams(_ x: Int,  _ y: Int) {  }
> func fooWithTuple(_ tuple: (Int, Int)) {  }
> 
> .. we should not be able to call
> 
> barParams(fooWithTuple) // should be error: incompatible types
> barTuple(fooWithParams) // should be error: incompatible types
> 
> 
> If so, are you suggesting that this code should still be valid?
> 
> barParams({tuple in}) // ?
> barTuple({x,y in}) // ?
> 
> 
> Will {x,y in} closure has ((Int, Int))->() type in this case?
> And if {tuple in} should be of type (Int,Int)->() ?
> 
> If I'm not missing something, the only reasonable solution here is follow the SE-0066 rules for function types and allow special syntax ((x,y)) to deconstruct tuple parts in closure argument list, and such closure will have type ((Int,Int))->() as expected. So we'll have:
> 
> barTuple({((x,y)) in ... })
> 
> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution