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 > <[email protected]> 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 >> <[email protected] <mailto:[email protected]>> 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 >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
