[swift-evolution] Revisiting SE-0110

John McCall rjmccall at apple.com
Fri May 26 10:29:01 CDT 2017

> On May 25, 2017, at 2:40 PM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
> On Thu, May 25, 2017 at 1:27 PM, John McCall via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> > On May 25, 2017, at 2:23 PM, Nevin Brackett-Rozinsky via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> 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. :)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170526/e492f2d5/attachment.html>

More information about the swift-evolution mailing list