On Thu, May 25, 2017 at 1:27 PM, John McCall via swift-evolution < [email protected]> wrote:
> > On May 25, 2017, at 2:23 PM, Nevin Brackett-Rozinsky via swift-evolution > <[email protected]> wrote: > > One possibility is to make parentheses consistently meaningful in > closure argument lists, so that “(a, b)” would exclusively mean “there is > one parameter of tuple-type, which is being destructured”, while “a, b” > without parentheses would exclusively mean “there are two parameters”. > > > > That way you can destructure a tuple parameter if you wish (by using > parentheses) or you can leave the tuple intact (by listing a single > identifier without parentheses). > > The problem with this is that we also need some way to be explicit about > the return type, and it would be strange to allow (and require!) > { a, b -> Int in } > when that's not at all a valid way to write a function type. Also it > would be an enormous source break, even worse than this problem. > > That said, I'm quite sympathetic to the idea that directly destructuring > tuples in closure parameter lists is too useful to lose, even if it's > ambiguous. > The option of using the keyword let to disambiguate, proposed somewhere above or on GitHub, is attractive here: { (a, b) -> Int in } // two parameters { let (a, b) -> Int in } // destructuring one parameter { a, let (b, c) -> Int in } // destructuring two parameters { let a, (b, c) -> Int in } // still destructuring two parameters { let (a, (b, c)) -> Int in } // destructuring one parameter { (a, (b, c)) -> Int in } // error: add 'let' to destructure second parameter
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
