<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div></div><div>On the contrary I think the solution can absolutely be to break other code. Allowing no parentheses is not a very useful shorthand -- it only saves two characters -- and with SE-0110 actually obscures the logic. Always requiring parentheses makes it clear that "{ (arg) in ..." can be replaced with "{ ((key, value)) in ..." when arg is a 2-tuple; the outer parentheses denote an argument list, and anything inside them is the argument, consistent with other parts of the language. Allowing "{ arg in ..." but not "{ (key, value) in ..." is sure to leave some people scratching their heads because<span style="background-color: rgba(255, 255, 255, 0);"> "{ arg in ..." suggests that it is arguments that are passed to closures (as is the case with functions) and not tuples.&nbsp;The correctness of "{ arg in ..." relies too heavily on the equivalence between a 1-tuple and a single element, an equivalence that does not hold for higher arities.</span></div><div><span style="background-color: rgba(255, 255, 255, 0);"><br></span></div><div><span style="background-color: rgba(255, 255, 255, 0);">I'm not *too* strongly wed to this, though. I care much more strongly about allowing&nbsp;&nbsp;"{ ((key, value)) in ..." than prohibiting&nbsp;&nbsp;"{ arg in ...". I only brought up the latter to try to improve the consistency of the language and to make clear that&nbsp;&nbsp;"{ ((key, value)) in ..." is the correct way of achieving the old style&nbsp;"{ (key, value) in ..."</span></div><div><br>On May 26, 2017, at 2:57 PM, Xiaodi Wu &lt;<a href="mailto:xiaodi.wu@gmail.com">xiaodi.wu@gmail.com</a>&gt; wrote:<br><br></div><blockquote type="cite"><div>Requiring parentheses in closures like that was discussed during SE-0110 and rejected; the rationale was that it's a useful shorthand, and that the whole closure syntax is wildly different from function declarations: you don't need to write the type of the arguments, and you don't need to write the return value, so why would it make sense to enforce this particular formality?<br><br>At this point, I'd be very much against now requiring it. The whole rationale for revisiting SE-0110 is that it is breaking lots of code, and the solution cannot be to break lots of other code. The double parenthesis syntax or the let syntax for destructuring seem to be fine mitigations, the former because it strictly parallels the change in syntax in SE-0110 where a single tuple argument has two sets of parentheses, and the latter because it's the same destructuring syntax as is used elsewhere for pattern matching.<br><div class="gmail_quote"><div dir="ltr">On Fri, May 26, 2017 at 11:45 David Sweeris via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
&gt; On May 26, 2017, at 08:14, Robert Bennett via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt; wrote:<br>
&gt;<br>
&gt; Alternatively, for maximum consistency we could make "{ arg in ..." illegal as well, requiring parentheses around "arg". This would mirror the parentheses necessary in e.g., "let f: (Int) -&gt; Int", and there would be no confusion as to why " { arg in ..." is legal but not "{ (key, value) in ...".<br>
<br>
I think I would support that. Until quite recently, I was under the impression that closures' "inner signatures" were part of that proposal, anyway.<br>
<br>
(Come to think of it... were they? I suppose it could be a bug that the "old" syntax is still accepted here.)<br>
<br>
- Dave Sweeris<br>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</blockquote></div>
</div></blockquote></body></html>