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

Fri May 5 02:22:28 CDT 2017

> 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 <mailto:david at hartbit.com>> wrote:
> 
> On 5 May 2017, at 07:17, Robert Widmann via swift-evolution <swift-evolution at swift.org <mailto: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 <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)

>> ~Robert Widmann
>> 
>>> On May 5, 2017, at 12:53 AM, Xiaodi Wu <xiaodi.wu at gmail.com <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 = 5
>>>> var y = 10
>>>> var 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 <mailto:swift-evolution at swift.org>
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <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/87020154/attachment.html>