[swift-evolution] Revisiting SE-0110

[Nevin Brackett-Rozinsky]

On Mon, May 29, 2017 at 10:47 PM, Robert Bennett <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.

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170530/ee4f66e6/attachment.html>