[swift-evolution] Revisiting SE-0110

[John McCall]

> On May 30, 2017, at 7:41 AM, Nevin Brackett-Rozinsky via swift-evolution <swift-evolution at swift.org> wrote:
> On Mon, May 29, 2017 at 10:47 PM, Robert Bennett <rltbennett at icloud.com <mailto:rltbennett at icloud.com>> wrote:
> I think the goal of SE 0110 and to a lesser extent 0066 was to disallow this level of intelligence in the compiler.
> 
> Interesting.
> 
> I happen to think that the goal of SE–110 <https://github.com/apple/swift-evolution/blob/master/proposals/0110-distingish-single-tuple-arg.md> 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.
> 
> 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.
> 
> With SE–66 <https://github.com/apple/swift-evolution/blob/master/proposals/0066-standardize-function-type-syntax.md> 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 core team’s notes <https://lists.swift.org/pipermail/swift-evolution-announce/2016-May/000138.html> 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.”
> 
> 
> While technically feasible, it's not desirable to overload parentheses in this manner.
> 
> I strongly disagree. Language features are desirable exactly to the extent that they make life better for developers.
> 
> 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.

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.

John.

> 
> 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.
> 
> 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 … }”.
> 
> 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.
> 
> Nevin
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170531/e87fbed2/attachment.html>