> On May 25, 2017, at 2:40 PM, Xiaodi Wu <[email protected]> wrote:
>
> On Thu, May 25, 2017 at 1:27 PM, John McCall via swift-evolution
> <[email protected] <mailto:[email protected]>> wrote:
> > On May 25, 2017, at 2:23 PM, Nevin Brackett-Rozinsky via swift-evolution
> > <[email protected] <mailto:[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
"attractive" might be an overstatement. :)
John.
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
