<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=""><div><blockquote type="cite" class=""><div class="">On May 30, 2017, at 7:41 AM, Nevin Brackett-Rozinsky via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote">On Mon, May 29, 2017 at 10:47 PM, Robert Bennett <span dir="ltr" class=""><<a href="mailto:rltbennett@icloud.com" target="_blank" class="">rltbennett@icloud.com</a>></span> wrote:<br class=""><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" class=""><div class=""></div><div class="">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 class=""><br class=""></div><div class="">Interesting.</div><div class=""><br class=""></div><div class="">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" class="">SE–110</a> was to make Swift'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 class=""></div><div class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">With <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0066-standardize-function-type-syntax.md" class="">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" class="">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 class=""><br class=""></div><div class=""><br class=""><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" class=""><div class=""></div><div class="">While technically feasible, it's not desirable to overload parentheses in this manner.</div></div></blockquote><div class=""><br class=""></div><div class="">I strongly disagree. Language features are desirable exactly to the extent that they make life better for developers.</div><div class=""><br class=""></div><div class="">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></div></div></div></blockquote><div><br class=""></div>This is basically my perspective. There are language features where we've made an intentional decision to require the user to write things in a specific way. Closure parameter lists are not one of them; we've already committed to using a very permissive and flexible grammar. Perhaps that was a mistake, but it's a mistake we've made and cannot reasonably undo, notwithstanding the proposals that are basically "we should ban such-and-such style that, coincidentally, I happen not to use." In the long term, I feel confident that we can deliver an implementation that resolves the multiple-parameter vs. tuple-decomposition ambiguity without making any significant compromises, but I'm not sure whether we can reasonably achieve that in 4.0.</div><div><br class=""></div><div>John.</div><div><br class=""><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="">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 class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">Nevin</div></div></div></div>
_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></body></html>