<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On May 25, 2017, at 2:40 PM, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" class="">xiaodi.wu@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">On Thu, May 25, 2017 at 1:27 PM, John McCall via swift-evolution <span dir="ltr" class=""><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>></span> wrote:<br class=""><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><span class="gmail-">> On May 25, 2017, at 2:23 PM, Nevin Brackett-Rozinsky via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class="">
> 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”.<br class="">
><br class="">
> 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).<br class="">
<br class="">
</span>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!)<br class="">
{ a, b -> Int in }<br class="">
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.<br class="">
<br class="">
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.<br class=""></blockquote><div class=""><br class=""></div><div class="">The option of using the keyword let to disambiguate, proposed somewhere above or on GitHub, is attractive here:</div></div></div></div></div></blockquote><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class=""><br class=""></div><div class="">{ (a, b) -> Int in } // two parameters<br class=""></div><div class=""><div class="">{ let (a, b) -> Int in } // destructuring one parameter</div></div><div class=""><br class=""></div><div class="">{ a, let (b, c) -> Int in } // destructuring two parameters</div><div class="">{ let a, (b, c) -> Int in } // still destructuring two parameters</div><div class="">{ let (a, (b, c)) -> Int in } // destructuring one parameter</div><div class="">{ (a, (b, c)) -> Int in } // error: add 'let' to destructure second parameter</div></div></div></div></div></blockquote><br class=""></div><div>"attractive" might be an overstatement. :)</div><div><br class=""></div><div>John.</div></body></html>