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

Fri May 5 00:17:47 CDT 2017

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.

~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 <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>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170505/09320ed8/attachment.html>