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

Fri May 5 02:24:49 CDT 2017

On Fri, May 5, 2017 at 2:22 AM, David Hart <david at hartbit.com> wrote:

>
> On 5 May 2017, at 07:56, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
>
> On Fri, May 5, 2017 at 12:54 AM, David Hart <david at hartbit.com> wrote:
>
>>
>> On 5 May 2017, at 07:17, Robert Widmann via swift-evolution <
>> swift-evolution at swift.org> 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.
>>
>> 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
>>
>> 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.
>>
>>
>> For what it's worth, I thought I knew Swift inside out and I had never
>> seen or used the syntax your are proposing to ban, so I'm all for it.
>>
>
> If you google "Swift tuple destructuring," it's demonstrated in the third
> link you can click on. The article is even titled "best practices":
>
> https://github.com/terhechte/appventure-blog/blob/master/
> resources/posts/2015-07-19-tuples-swift-advanced-usage-best-practices.org
>
>
> I do know and use tuple destructuring. But AFAIK, that’s not the syntax
> Robert wants to ban: its the labels in that syntax. As he says:
>
> *Note that a tuple shuffle is distinct from a re-assignment through a
> tuple pattern. For example, this series of statements will continue to
> function as before:*
> *(z, y, x) = (x, z, y)*
>

I'n not saying that you don't know about tuple destructuring. I'm saying
that the particular feature Robert wants to ban is covered in the article I
linked to, which at least Google thinks is one of the most relevant
articles on tuple destructuring in Swift. So, it's not as rare as Robert
makes it out to be; plenty of people have talked about it.

~Robert Widmann
>>
>> On May 5, 2017, at 12:53 AM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
>>
>> Ah, I see from your proposed grammar update: you're proposing to prohibit
>> the use of labels entirely in a tuple pattern.
>>
>> This is much more than just prohibiting tuple shuffling, and I'm rather
>> disappointed that you described such a dramatic change using a corner case.
>> There are very good reasons why someone finds 'let (y: x, x: y) = (x: 1, y:
>> 2)' confusing and would support its removal, but it is entirely another
>> ballgame to remove labels from tuple patterns altogether.
>>
>>
>> On Thu, May 4, 2017 at 23:47 Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
>>
>>> Now I'm confused. The ordinary meaning of the word "shuffle" is not
>>> changing but rather reordering, and all of your examples are of reordering.
>>>
>>> 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.
>>>
>>> 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).
>>>
>>> Either one of these scenarios is commonly used, and it is astonishing to
>>> me that they would be eliminated.
>>>
>>> On Thu, May 4, 2017 at 23:28 Robert Widmann <devteam.codafi at gmail.com>
>>> wrote:
>>>
>>>> That doesn't involve a parameter *reordering*, but because it changes
>>>> argument labels it's a shuffle.
>>>>
>>>> ~Robert Widmann
>>>>
>>>> 2017/05/05 0:16、Xiaodi Wu <xiaodi.wu at gmail.com> のメッセージ:
>>>>
>>>> Robert,
>>>>
>>>> As I mentioned on Twitter, getting rid of tuple shuffles would not cure
>>>> your example, which does not involve a shuffle. Unless you're proposing to
>>>> disallow the use of labels during destructuring entirely, which I would
>>>> think to be very much unacceptable. Example:
>>>>
>>>> ```
>>>> let (partialValue: v, overflow: o) = 42.addingReportingOverflow(42)
>>>> ```
>>>>
>>>> This involves no shuffling and should absolutely remain allowed.
>>>>
>>>>
>>>> On Thu, May 4, 2017 at 21:15 Robert Widmann via swift-evolution <
>>>> swift-evolution at swift.org> wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> So sorry that this proposal comes so late in the game, but I feel it’s
>>>>> too important not to bring it to the attention of the community now.
>>>>> Attached is a proposal to deprecate a language feature many of you will
>>>>> probably have never had the chance to use: Tuple Shuffles.  I’ve attached a
>>>>> copy of the first draft of the proposal below, but the latest copy can be
>>>>> read on Github
>>>>> <https://github.com/apple/swift-evolution/pull/705/files>.
>>>>>
>>>>> Thanks!
>>>>>
>>>>> ~Robert Widmann
>>>>>
>>>>> Deprecate Tuple Shuffles
>>>>>
>>>>>    - Proposal: SE-NNNN
>>>>>    <https://github.com/CodaFi/swift-evolution/blob/8eaf320b3c2a117909fc0269c398e89c033a4b9f/proposals/NNNN-filename.md>
>>>>>    - Authors: Robert Widmann <https://github.com/codafi>
>>>>>    - Review Manager: TBD
>>>>>    - Status: Awaiting review
>>>>>
>>>>>
>>>>> <https://github.com/CodaFi/swift-evolution/blob/8eaf320b3c2a117909fc0269c398e89c033a4b9f/proposals/NNNN-deprecate-tuple-shuffles.md#introduction>
>>>>> Introduction
>>>>>
>>>>> This proposal seeks the deprecation of a little-known feature of Swift
>>>>> called a "Tuple Shuffle".
>>>>>
>>>>> <https://github.com/CodaFi/swift-evolution/blob/8eaf320b3c2a117909fc0269c398e89c033a4b9f/proposals/NNNN-deprecate-tuple-shuffles.md#motivation>
>>>>> Motivation
>>>>>
>>>>> A tuple-shuffle is an undocumented feature of Swift in which one can
>>>>> re-order the indices of a tuple by writing a pattern that describes a
>>>>> permutation in a syntax reminiscent of adding type-annotations to a
>>>>> parameter list:
>>>>>
>>>>> let a = (x: 1, y: 2)var b: (y: Int, x: Int)
>>>>> b = a
>>>>>
>>>>> It can be used to simultaneously destructure and reorder a tuple:
>>>>>
>>>>> let tuple = (first: 0, second: (x: 1, y: 2))let (second: (x: b, y: c), first: a) = tuple
>>>>>
>>>>> It can also be used to map parameter labels out of order in a call
>>>>> expression:
>>>>>
>>>>> func foo(_ : (x : Int, y : Int)) {}foo((y: 5, x: 10)) // Valid
>>>>>
>>>>> Note that a tuple shuffle is distinct from a re-assignment through a
>>>>> tuple pattern. For example, this series of statements will continue to
>>>>> function as before:
>>>>>
>>>>> var x = 5var y = 10var z = 15
>>>>> (z, y, x) = (x, z, y)
>>>>>
>>>>> Their inclusion in the language complicates every part of the compiler
>>>>> stack, uses a syntax that can be confused for type annotations
>>>>> <https://twitter.com/CodaFi_/status/860246169854894081>, contradicts
>>>>> the goals of earlier SE's (see SE-0060
>>>>> <https://github.com/apple/swift-evolution/blob/9cf2685293108ea3efcbebb7ee6a8618b83d4a90/proposals/0060-defaulted-parameter-order.md>),
>>>>> and makes non-sensical patterns possible in surprising places.
>>>>>
>>>>> Take switch-statements, for example:
>>>>>
>>>>> switch ((0, 0), 0){ case (_ : let (y, z), _ : let s): () // We are forbidden from giving these patterns names other than "_" default: ()
>>>>> }
>>>>>
>>>>> This proposal seeks to deprecate them in Swift 3 compatibility mode
>>>>> and enforce that deprecation as a hard error in Swift 4 to facilitate their
>>>>> eventual removal from the language.
>>>>>
>>>>> <https://github.com/CodaFi/swift-evolution/blob/8eaf320b3c2a117909fc0269c398e89c033a4b9f/proposals/NNNN-deprecate-tuple-shuffles.md#proposed-solution>Proposed
>>>>> solution
>>>>>
>>>>> Construction of Tuple Shuffle Expressions will become a warning in
>>>>> Swift 3 compatibility mode and will be a hard-error in Swift 4.
>>>>>
>>>>> <https://github.com/CodaFi/swift-evolution/blob/8eaf320b3c2a117909fc0269c398e89c033a4b9f/proposals/NNNN-deprecate-tuple-shuffles.md#detailed-design>Detailed
>>>>> design
>>>>>
>>>>> In addition to the necessary diagnostics, the grammar will be ammended
>>>>> to simplify the following productions:
>>>>>
>>>>> tuple-pattern → (tuple-pattern-element-list <opt>)
>>>>> tuple-pattern-element-list → tuple-pattern-element | tuple-pattern-element , tuple-pattern-element-list- tuple-pattern-element → pattern | identifier:pattern+ tuple-pattern-element → pattern
>>>>>
>>>>>
>>>>> <https://github.com/CodaFi/swift-evolution/blob/8eaf320b3c2a117909fc0269c398e89c033a4b9f/proposals/NNNN-deprecate-tuple-shuffles.md#impact-on-existing-code>Impact
>>>>> on Existing Code
>>>>>
>>>>> Because very little code is intentionally using Tuple Shuffles, impact
>>>>> on existing code will be negligible but not non-zero.
>>>>>
>>>>> <https://github.com/CodaFi/swift-evolution/blob/8eaf320b3c2a117909fc0269c398e89c033a4b9f/proposals/NNNN-deprecate-tuple-shuffles.md#alternatives-considered>Alternatives
>>>>> considered
>>>>> Continue to keep the architecture in place to facilitate this feature.
>>>>> _______________________________________________
>>>>> 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/20170505/14bb8ac6/attachment.html>