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

[Xiaodi Wu]

On Fri, May 5, 2017 at 12:42 AM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:

> On Fri, May 5, 2017 at 00:17 Robert Widmann <devteam.codafi at gmail.com>
> wrote:
>
>> On the contrary, this is precisely what it means to deprecate tuple
>> shuffles.  You can’t map common parlance onto this term; the proposal and
>> the Twitter thread weren’t merely about reordering arguments.
>>
>
> Let's be clear: _all_ of your examples of "shuffles" in the proposal
> involve reordering. You defined a tuple shuffle as such: "an undocumented
> feature of Swift in which one can re-order the indices of a tuple...." If
> you intend to propose a broader change, it is grossly misleading to write
> it up in this way.
>
> but it is entirely another ballgame to remove labels from tuple patterns
>> altogether.
>>
>>
>> It’s really not.  Let me demonstrate:
>>
>> To be clear, are you proposing the prohibition of *adding or removing*
>>> labels as well? A previous discussion on tuple shuffling on this list saw
>>> consensus that assigning a value of type (label1: T, label2: U) to a
>>> variable of type (T, U) and vice versa should absolutely be supported,
>>> whether or not reordering is permitted.
>>
>>
>> I am not proposing any changes to switching parameter labels through
>> well-typed re-assignments.  This is absolutely still going to be allowed:
>>
>> var z : (Int, Int) = (0, 0)
>> var w : (x : Int, y : Int) = (5, 10)
>> z = w
>> w = z
>>
>> This is modeled internally with a tuple shuffle, but not the kind of
>> shuffle I’m interested in banning.  It’s a far simpler kind of
>>
>
> What is your proposed behavior for the following code?
>
> ```
> let x: (r: Int, g: Int, b: Int, a: Int) = (255, 255, 255, 0)
> let y: (a: Int, r: Int, g: Int, b: Int) = x
>
> print(y.a) // currently, prints "0"
> ```
>
> Either you are proposing only to remove labels from tuple patterns, which
> does not at all prohibit reordering, or you are proposing to prohibit
> reordering, in which case this code has an error--or it doesn't and you've
> instead _silently_ changed the behavior of existing code. One can live with
> warnings and even errors, but a silent change to existing code is the stuff
> of nightmares, and I would be strongly opposed to that.
>
>
>>
>> And how about *restating* existing labels without any adding or removing?
>>> To be clear:
>>>
>>> ```
>>> let (partialValue: v, overflow: o) = 42.addingReportingOverflow(42)
>>> ```
>>>
>>> ...involves absolutely no changes in labels whatsoever. The return type
>>> is (partialValue: Int, overflow: ArithmeticOverflow).
>>>
>>
>> That, however, is a kind of shuffle I intend to deprecate here.  This
>> kind of pattern is subject to the “arcane syntax” part of the proposal.
>>
>>
>>> Either one of these scenarios is commonly used, and it is astonishing to
>>> me that they would be eliminated.
>>
>>
>> Do you have proof of that claim? I have never seen the relevant kinds of
>> tuple shuffle used before, and I doubt you have either before today.
>>
>
> Huh? I use it pervasively. Currently, writing out labels during
> destructuring guarantees that, even if I've incorrectly memorized the order
> of the values in a tuple, the tuple is still destructured as I expect. And
> if reordering were not a feature of Swift, I would still write out these
> labels. In that case, it would be a static assertion that destructuring is
> happening in the expected order. That is, if I try to destructure a tuple
> of type (r: Int, g: Int, b: Int, a: Int) and accidentally write 'let (a:
> alpha, r: _, g: green, b: _) = ...', I'd get an error and find my mistake
> at compile time.
>
> The whole point of having labels in the first place is clarity at the
> point of use. Just as SE-0111 will need revision because it removed a key
> documentation use for argument labels, forbidding labels in tuple patterns
> would make the same mistake for tuples.
>

I should add, it boggles the mind that you would claim that people will
have never heard of this before today. It's been discussed _on this very
list_!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170505/c74052b9/attachment.html>