Requiring parentheses in closures like that was discussed during SE-0110 and rejected; the rationale was that it&#39;s a useful shorthand, and that the whole closure syntax is wildly different from function declarations: you don&#39;t need to write the type of the arguments, and you don&#39;t need to write the return value, so why would it make sense to enforce this particular formality?<br><br>At this point, I&#39;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&#39;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 &quot;{ arg in ...&quot; illegal as well, requiring parentheses around &quot;arg&quot;. This would mirror the parentheses necessary in e.g., &quot;let f: (Int) -&gt; Int&quot;, and there would be no confusion as to why &quot; { arg in ...&quot; is legal but not &quot;{ (key, value) in ...&quot;.<br>
<br>
I think I would support that. Until quite recently, I was under the impression that closures&#39; &quot;inner signatures&quot; were part of that proposal, anyway.<br>
<br>
(Come to think of it... were they? I suppose it could be a bug that the &quot;old&quot; 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>