[swift-evolution] [Proposal][Discussion] Deprecate Tuple Shuffles

[Xiaodi Wu]

On Mon, May 8, 2017 at 3:08 AM, Brent Royal-Gordon <brent at architechies.com>
wrote:

> On May 8, 2017, at 12:09 AM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
>
> Highly disagree. Consistency teaches us that variables can come after a
> colon.
>
>
> But not normally in a declaration.
>
> On May 8, 2017, at 12:28 AM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
>
> Yes, Robert came up with a very clever puzzle. I'll bet you there are
> *plenty* of neat puzzles that you can come up with if you start naming your
> variables `Int` and `Double`.
>
>
> Sure, but how many of them look *so much* like a declaration that, even
> knowing there's a puzzle, you still don't guess what's going on? Because
> that was my experience with his "puzzle".
>

So, then, the puzzle puzzled you.

I know that Swift pattern matching is based on the idea that the pattern
> looks like the code used to construct the value it matches. But in the case
> of capturing values from labeled paren lists, I think it leads to deeply
> confusing code. We already knew about the weirdness of `as` in pattern
> matches, but this is even worse.
>
> I think we ought to reconsider what we're doing in this area, and perhaps
> move more towards a syntax that echoes declaration rather than use. When a
> piece of syntax *really* looks like it does A, even to experienced users,
> but it actually does B, that's a sign that it's the wrong syntax.
>

Again, if you were to write this piece of code yourself, a whole slew of
warnings would tell you unambiguously that it's B and not A. It would warn
you that `Int` and `Double` are never used before you even typed the second
line. If you tried to use `x` and `y`, it would error and tell you they've
not been declared. If the tuple had two homogeneous elements, it would have
given an error that you'd redeclared the same variable twice.

And if those aren't enough, it is possible to add warnings about variable
names that shadow type names (which may have broader benefits and is worth
consideration) and it is possible to add warnings when labels are used to
destructure a tuple that doesn't come with its own labels.

To demonstrate where the puzzle ended up being very clever, consider this
one-liner:

```
print(Int + Double) // Prints "4".
```

This alone will *really* look like something it is not even to experienced
users; it involves no tuples or pattern matching. (Interestingly, without
an implementation of the proposal accepted long ago to remove `.self` from
the language, one actually cannot make this happen in the following way; in
other words, `Int` and `Double` in that context currently _cannot_ be
types.)

```
func + <T, U>(_: T.Type, _: U.Type) -> Int { return 4 }
// However, one must write `Int.self + Double.self`
```

But in any case, the original point I was making in response to Robert's
original proposal is that getting rid of tuple shuffles is a topic that's
orthogonal to pattern matching syntax. If you want to redesign all of
pattern matching syntax for Swift, that's a conversation for another day.
Just note that `if/for/while let` syntax went through a controversial
overhaul for Swift 3, and a proposal to change enum case pattern matching
only just got accepted with revisions last month and hasn't even been
implemented yet for Swift 4. This is getting very near access modifiers in
terms of churn during every release of Swift.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170508/14447bf7/attachment.html>