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

[Xiaodi Wu]

On Mon, May 8, 2017 at 1:30 AM, Adrian Zubarev via swift-evolution <
swift-evolution at swift.org> wrote:

> Exactly, everything else is simply an excuse and nothing more. Tuple
> destructuring is not even aligned to enum case patterns at all, because it
> only uses the shorthand version and does not allow us to write the full
> explicit version.
>
> enum Foo { case a(b: Int, c: Int) }
>
> switch Foo.a(b: 42, c: 0) {
>     case let .a(b: num1, c: num2): …
>
>
You've just demonstrated how enum case patterns align with tuple patterns.
This is exactly the same syntax. Here, too, no type is allowed after the
colon. In fact, during discussion about allowing cases with the same base
name, it was shown that overloading cases would be tricky precisely because
of this: you're not allowed to disambiguate by writing `case let .a(b:
num1: Int, c: num2: Int)` if two cases differ only by the type of their
arguments.

>
>
>     // Or the explicit longer version:
>     case .a(b: let num1, c: let: num2): …
> }
>
> Tuple destructuring do not support the latter, which in our previous
> example would really be unambiguous.
>
> let tuple: (x: Int, y: Int) = (3, 1)
>
> // Short version:
> let (x: Int, y: Double): (x: Int, y: Int) = tuple
>
> // Not supported explicit version:
> (x: let Int, y: let Double) = tuple
>
> Why is that the case? Because tuple destructuring creates another tuple on
> the left side of the same tuple type as the tuple on the right side of the
> assignment operator.
>

I see no reason why that syntax could not also be supported, other than
that there's no demand for it.


> Erica Sudan has a proposal, which could change that for guards and ifs
> (second design): https://github.com/erica/swift-evolution/blob/
> 783fdf8d3723d51f350b917af23c207cebdd1ad7/proposals/9999-ifcaseguardcase.md
>
>
>
> --
> Adrian Zubarev
> Sent with Airmail
>
> Am 8. Mai 2017 um 07:16:50, David Hart via swift-evolution (
> swift-evolution at swift.org) schrieb:
>
>
> On 7 May 2017, at 00:21, Xiaodi Wu via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> To which human would it be misleading?
>
> To the writer? No, because the compiler will warn you right away. By the
> time you're done with writing the first line, it'll warn you that Int and
> Double are unused variables. And if you try to use x and y, you get an
> error.
>
> To the reader? Only if the writer knowingly wrote this misleading code. In
> other words, it's a nice puzzle, but no reader will encounter this in
> real-world code, unless they're being tormented by the writer on purpose.
>
>
> IMHO, the fact that the compiler warns you does no change the fact that
> it's a very confusing part of the language. It should not be an excuse for
> fixing it. Consistency teaches us to expect a type after a colon.
>
> On Sat, May 6, 2017 at 16:28 Brent Royal-Gordon <brent at architechies.com>
> wrote:
>
>> > On May 5, 2017, at 11:06 PM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
>> >
>> > The identifier after a colon is *never* a type in any pattern matching,
>> and there's no need of which I'm aware to support type annotations in
>> pattern matching. We put colons after labels, and the current syntax is
>> perfectly consistent here. What is the defect you're trying to cure?
>>
>> The defect underlying this proposal: `let (x: Int, y: Double)` looks like
>> it's declaring `x` and `y` of types `Int` and `Double`, but it's actually
>> declaring `Int` and `Double` and binding them to `x` and `y`. Your code's
>> meaning is perfectly unambiguous to the compiler, of course, but it's
>> misleading to the human.
>>
>> --
>> Brent Royal-Gordon
>> Architechies
>>
>> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> _______________________________________________
> 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/20170508/ce5ecb54/attachment.html>