> On May 30, 2017, at 7:41 AM, Nevin Brackett-Rozinsky via swift-evolution
> <[email protected]> wrote:
> On Mon, May 29, 2017 at 10:47 PM, Robert Bennett <[email protected]
> <mailto:[email protected]>> 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
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
