<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, May 29, 2017 at 10:47 PM, Robert Bennett <span dir="ltr">&lt;<a href="mailto:rltbennett@icloud.com" target="_blank">rltbennett@icloud.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div></div><div>I think the goal of SE 0110 and to a lesser extent 0066 was to disallow this level of intelligence in the compiler.</div></div></blockquote><div><br></div><div>Interesting.</div><div><br></div><div>I happen to think that the goal of <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0110-distingish-single-tuple-arg.md">SE–110</a> was to make Swift&#39;s type system “properly distinguish between functions that take one tuple argument, and functions that take multiple arguments.” Nowhere does that proposal discuss tuple destructuring, and nowhere does it discuss optional parentheses around closure parameter lists.<br></div><div><br></div><div>I might go so far as to say that any commits which *do* affect those things, cannot possibly be correct implementations of the accepted proposal SE–110, because SE–110 did not describe any changes there.</div><div><br></div><div>With <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0066-standardize-function-type-syntax.md">SE–66</a> the case is even more clearcut: that proposal explicitly addresses the question, “Should we require parentheses in closure expression parameter lists?“ and answers it in the negative. The <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-May/000138.html">core team’s notes</a> on accepting also specify, “The core team did not feel that this proposal needed to include required parentheses within closures, which have their own fairly specific grammar.”</div><div><br></div><div><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div></div><div>While technically feasible, it&#39;s not desirable to overload parentheses in this manner.</div></div></blockquote><div><br></div><div>I strongly disagree. Language features are desirable exactly to the extent that they make life better for developers.</div><div><br></div><div>Moreover, parentheses are *already* optional in closure parameter lists. Making them mandatory would be source-breaking for no benefit to programmers. Plus having to write double-parentheses in “dict.map{ ((key, value)) in … }” would be needlessly annoying.</div></div><div><br></div><div>In my view there have been far too many calls for making Swift “consistent” in ways that actually make it less enjoyable to use. That is the opposite of “Swifty”, and we should instead prioritize convenience for users above rigid consistency of implementation.</div><div><br></div><div>In the case at hand, with Dictionary.map, the vast majority of the time the user doesn’t actually care whether the closure takes two arguments or a single 2-tuple argument. They just know that it takes a key and a value, and they want to be able to write “dict.map{ (key, value) in … }”.</div><div><br></div><div>Sure, the closure *does* take a 2-tuple, and it does not take two arguments, but the programmer *using* it shouldn’t have to bother about that distinction most of the time. They just want to assign the key to one identifier and the value to another. If they try to write “key, value” without any parentheses the compiler will complain and they’ll add the parens. But if the compiler demands a *second* set of parentheses, that will just seem ridiculous.</div><div><br></div><div>Nevin</div></div></div></div>