[swift-evolution] Revisiting SE-0110

[Xiaodi Wu]

On Thu, May 25, 2017 at 1:27 PM, John McCall via swift-evolution <
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> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170525/48972f55/attachment.html>