[Proposal][Discussion] Deprecate Tuple Shuffles

[codafi (Robert Widmann)]

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 <[Proposal] Deprecate Tuple Shuffle Expressions by CodaFi · Pull Request #705 · apple/swift-evolution · GitHub.

Thanks!

~Robert Widmann

Deprecate Tuple Shuffles

Proposal: SE-NNNN <https://github.com/CodaFi/swift-evolution/blob/8eaf320b3c2a117909fc0269c398e89c033a4b9f/proposals/NNNN-filename.md&gt;
Authors: Robert Widmann <https://github.com/codafi&gt;
Review Manager: TBD
Status: Awaiting review
<swift-evolution/NNNN-deprecate-tuple-shuffles.md at 8eaf320b3c2a117909fc0269c398e89c033a4b9f · CodaFi/swift-evolution · GitHub

This proposal seeks the deprecation of a little-known feature of Swift called a "Tuple Shuffle".

<swift-evolution/NNNN-deprecate-tuple-shuffles.md at 8eaf320b3c2a117909fc0269c398e89c033a4b9f · CodaFi/swift-evolution · GitHub

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&gt;, contradicts the goals of earlier SE's (see SE-0060 <https://github.com/apple/swift-evolution/blob/9cf2685293108ea3efcbebb7ee6a8618b83d4a90/proposals/0060-defaulted-parameter-order.md&gt;\), 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.

<swift-evolution/NNNN-deprecate-tuple-shuffles.md at 8eaf320b3c2a117909fc0269c398e89c033a4b9f · CodaFi/swift-evolution · GitHub solution

Construction of Tuple Shuffle Expressions will become a warning in Swift 3 compatibility mode and will be a hard-error in Swift 4.

<swift-evolution/NNNN-deprecate-tuple-shuffles.md at 8eaf320b3c2a117909fc0269c398e89c033a4b9f · CodaFi/swift-evolution · GitHub 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
<swift-evolution/NNNN-deprecate-tuple-shuffles.md at 8eaf320b3c2a117909fc0269c398e89c033a4b9f · CodaFi/swift-evolution · GitHub on Existing Code

Because very little code is intentionally using Tuple Shuffles, impact on existing code will be negligible but not non-zero.

<swift-evolution/NNNN-deprecate-tuple-shuffles.md at 8eaf320b3c2a117909fc0269c398e89c033a4b9f · CodaFi/swift-evolution · GitHub considered

Continue to keep the architecture in place to facilitate this feature.

[Felix_Cloutier1 (Félix Cloutier)]

Why?

···

Le 4 mai 2017 à 19:14, Robert Widmann via swift-evolution <swift-evolution@swift.org> a écrit :

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 <[Proposal] Deprecate Tuple Shuffle Expressions by CodaFi · Pull Request #705 · apple/swift-evolution · GitHub.

Thanks!

~Robert Widmann

Deprecate Tuple Shuffles

Proposal: SE-NNNN <https://github.com/CodaFi/swift-evolution/blob/8eaf320b3c2a117909fc0269c398e89c033a4b9f/proposals/NNNN-filename.md&gt;
Authors: Robert Widmann <https://github.com/codafi&gt;
Review Manager: TBD
Status: Awaiting review
<https://github.com/CodaFi/swift-evolution/blob/8eaf320b3c2a117909fc0269c398e89c033a4b9f/proposals/NNNN-deprecate-tuple-shuffles.md#introduction&gt;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&gt;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&gt;, contradicts the goals of earlier SE's (see SE-0060 <https://github.com/apple/swift-evolution/blob/9cf2685293108ea3efcbebb7ee6a8618b83d4a90/proposals/0060-defaulted-parameter-order.md&gt;\), 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&gt;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&gt;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&gt;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&gt;Alternatives considered

Continue to keep the architecture in place to facilitate this feature.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[masters3d]

I can't think of a single time when I would need a tuple shuffle but I don't really work with tuples much. It would be great to hear other people's usage of this feature.

I did not know that types could be overloaded with values. That was very surprising to me. Honestly I think that is the issue here. Not sure what can be done about it.

let Int = 5 // works
let Void = "what?" // works.

···

On May 4, 2017, at 7:14 PM, Robert Widmann via swift-evolution <swift-evolution@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.

Thanks!

~Robert Widmann

Deprecate Tuple Shuffles
Proposal: SE-NNNN
Authors: Robert Widmann
Review Manager: TBD
Status: Awaiting review
Introduction

This proposal seeks the deprecation of a little-known feature of Swift called a "Tuple Shuffle".

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, contradicts the goals of earlier SE's (see SE-0060), 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.

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.

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
Impact on Existing Code

Because very little code is intentionally using Tuple Shuffles, impact on existing code will be negligible but not non-zero.

Alternatives considered

Continue to keep the architecture in place to facilitate this feature.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[codafi (Robert Widmann)]

To clarify for the root. Disregard the “Detailed Design” section attached to this email. The proposal on Github no longer seeks to remove labeled tuple patterns from the language.

···

On May 4, 2017, at 10:14 PM, Robert Widmann <devteam.codafi@gmail.com> 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 <[Proposal] Deprecate Tuple Shuffle Expressions by CodaFi · Pull Request #705 · apple/swift-evolution · GitHub.

Thanks!

~Robert Widmann

Deprecate Tuple Shuffles

Proposal: SE-NNNN <https://github.com/CodaFi/swift-evolution/blob/8eaf320b3c2a117909fc0269c398e89c033a4b9f/proposals/NNNN-filename.md&gt;
Authors: Robert Widmann <https://github.com/codafi&gt;
Review Manager: TBD
Status: Awaiting review
<https://github.com/CodaFi/swift-evolution/blob/8eaf320b3c2a117909fc0269c398e89c033a4b9f/proposals/NNNN-deprecate-tuple-shuffles.md#introduction&gt;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&gt;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&gt;, contradicts the goals of earlier SE's (see SE-0060 <https://github.com/apple/swift-evolution/blob/9cf2685293108ea3efcbebb7ee6a8618b83d4a90/proposals/0060-defaulted-parameter-order.md&gt;\), 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&gt;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&gt;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&gt;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&gt;Alternatives considered

Continue to keep the architecture in place to facilitate this feature.

[xwu (Xiaodi Wu)]

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@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 <[Proposal] Deprecate Tuple Shuffle Expressions by CodaFi · Pull Request #705 · apple/swift-evolution · GitHub.

Thanks!

~Robert Widmann

Deprecate Tuple Shuffles

   - Proposal: SE-NNNN
   <https://github.com/CodaFi/swift-evolution/blob/8eaf320b3c2a117909fc0269c398e89c033a4b9f/proposals/NNNN-filename.md&gt;
   - Authors: Robert Widmann <https://github.com/codafi&gt;
   - Review Manager: TBD
   - Status: Awaiting review

<https://github.com/CodaFi/swift-evolution/blob/8eaf320b3c2a117909fc0269c398e89c033a4b9f/proposals/NNNN-deprecate-tuple-shuffles.md#introduction&gt;
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&gt;
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&gt;, contradicts the
goals of earlier SE's (see SE-0060
<https://github.com/apple/swift-evolution/blob/9cf2685293108ea3efcbebb7ee6a8618b83d4a90/proposals/0060-defaulted-parameter-order.md&gt;\),
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&gt;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&gt;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&gt;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&gt;Alternatives
considered
Continue to keep the architecture in place to facilitate this feature.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[DevAndArtist (Adrian Meister)]

Hi Robert,

I’m trying to understand the impact of your proposal and the feature you want to remove from the language. Could you describe a little more on how if ever this affects tuple destructuring?

var (a, b, c) = (0, "", 0)

(a, b) = (42, "Hello Swift")

(a = 42, b = "Hello Swift")

var (x, y) = (0, 42)

(x, y) = (y, x) // swap without a temporary value

···

--
Adrian Zubarev
Sent with Airmail

Am 5. Mai 2017 um 04:15:12, Robert Widmann via swift-evolution (swift-evolution@swift.org) schrieb:

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.

Thanks!

~Robert Widmann

Deprecate Tuple Shuffles
Proposal: SE-NNNN
Authors: Robert Widmann
Review Manager: TBD
Status: Awaiting review
Introduction

This proposal seeks the deprecation of a little-known feature of Swift called a "Tuple Shuffle".

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, contradicts the goals of earlier SE's (see SE-0060), 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.

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.

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
Impact on Existing Code

Because very little code is intentionally using Tuple Shuffles, impact on existing code will be negligible but not non-zero.

Alternatives considered

Continue to keep the architecture in place to facilitate this feature.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[Haravikk3 (Haravikk)]

I have to admit I've become confused by what exactly this proposal is trying to fix as there's a lot of talk about removing labels entirely or something? I'm very wary about that.

let a = (x: 1, y: 2)
var b: (y: Int, x: Int)
b = a

However, for this specific case above I do agree that a warning should be added, as the implicit behaviour here could all too easily be a mistake. I would prefer instead the developers either manually reorder the values, and perhaps that an operator be added to explicitly perform automatic reordering. Perhaps a tilde? Like so:

  let a = (x: 1, y: 2)
  var b: (y:Int, x:Int)

  b = a // warning
  b = (x: a.x, y: a.y) // explicit, manual reordering
  b = ~a // implicit, automatic reordering by label matching (still warns/errors on type mismatch)

As for any other changes however, I think these should be addressed in their own proposals as I think discussion is getting too broad and confusing IMO.

···

On 5 May 2017, at 03:14, Robert Widmann via swift-evolution <swift-evolution@swift.org> wrote:

[tonyarnold]

Why?

Not trying to be smart, but the reasoning is in Robert’s proposal:

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), and makes non-sensical patterns possible in surprising places.

Robert, maybe you could include some detail about how this feature is complicating the compiler stack, and what will be improved by it’s removal?

···

On 5 May 2017, at 12:27, Félix Cloutier via swift-evolution <swift-evolution@swift.org> wrote:

====

That being said, I’m all for you guys making your lives easier at the cost of something we shouldn’t be using in the first place…

Tony

----------
Tony Arnold
+61 411 268 532
http://thecocoabots.com/

ABN: 14831833541

[VladimirS (Vladimir)]

I can't think of a single time when I would need a tuple shuffle but I don't really work with tuples much. It would be great to hear other people's usage of this feature.

I did not know that types could be overloaded with values. That was very surprising to me. Honestly I think that is the issue here. Not sure what can be done about it.

let Int = 5 // works
let Void = "what?" // works.

Very interesting. Could some one clarify, why this is allowed? Isn't this is a bug we want to fix? At least by requiring a tilda like `Int`
And of course, you can't "overload" user defined type:
struct S {}
let S = 10 // Error: invalid redeclaration of 'S'

···

On 05.05.2017 6:12, Jose Cheyo Jimenez via swift-evolution wrote:

On May 4, 2017, at 7:14 PM, Robert Widmann via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@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 <[Proposal] Deprecate Tuple Shuffle Expressions by CodaFi · Pull Request #705 · apple/swift-evolution · GitHub.

Thanks!

~Robert Widmann

  Deprecate Tuple Shuffles

  * Proposal: SE-NNNN
    <https://github.com/CodaFi/swift-evolution/blob/8eaf320b3c2a117909fc0269c398e89c033a4b9f/proposals/NNNN-filename.md&gt;
  * Authors: Robert Widmann <https://github.com/codafi&gt;
  * Review Manager: TBD
  * Status: Awaiting review

    <https://github.com/CodaFi/swift-evolution/blob/8eaf320b3c2a117909fc0269c398e89c033a4b9f/proposals/NNNN-deprecate-tuple-shuffles.md#introduction&gt;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&gt;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&gt;, contradicts the goals of earlier SE's (see SE-0060 <https://github.com/apple/swift-evolution/blob/9cf2685293108ea3efcbebb7ee6a8618b83d4a90/proposals/0060-defaulted-parameter-order.md&gt;\), 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&gt;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&gt;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&gt;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&gt;Alternatives
    considered

Continue to keep the architecture in place to facilitate this feature.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[Erica_Sadun]

I'm coming into this ridiculously late. Apologies, but I've had family responsibilities. I've tried to read through the thread before replaying. I hope I have not missed any significant points.

First, I dislike calling this "tuple shuffles". That phrase has an existing and useful meaning in the Swift community. It refers to what this proposal calls "re-assignment through a tuple pattern". This is what I want to keep calling a "tuple shuffle":

`(a, b, c) = (b, c, a)`

I'd rather call the problem space for this proposal "label-led tuple assignment" (or something like that) and reserve "tuple shuffle" for reordered value reassignment.

Second, I agree with TJ. I dislike that this pattern is legal:

// Declare using labels
let rgba: (r: Int, g: Int, b: Int, a: Int) = (255, 255, 255, 0)

// Declare using re-ordered labels
let argb: (a: Int, r: Int, g: Int, b: Int) = rgba // This is the line I have issue with

print(argb.a) // "0"

I find this usage counter to Swift's philosophy of clarity and simplicity. It is sufficiently obscure that I consider it a non-standard use regardless of Wux's Google search results.

Consider the example of Joe Groff's SE-0060 (https://github.com/apple/swift-evolution/blob/master/proposals/0060-defaulted-parameter-order.md\). I believe it's reasonable to mandate that the order of labels in declarations be ignored, with the types being compiler-checked. I'd envision that the "correct" behavior should act like this instead:

// Declare using re-ordered labels
let argb: (a: Int, r: Int, g: Int, b: Int) = rgba // (Int, Int, Int, Int) assigned to (Int, Int, Int, Int)

print(argb.a) // "255"

This reworking is partially inspired by SE-0111 (https://github.com/apple/swift-evolution/blob/master/proposals/0111-remove-arg-label-type-significance.md\), ensuring that the tuple argument labels are not considered in typing the new constant. In fact, this entire proposal might be better named "Removing the Ordering Significance of Tuple Argument Labels in Declarations"

-- E

···

On May 4, 2017, at 8:14 PM, Robert Widmann via swift-evolution <swift-evolution@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 <[Proposal] Deprecate Tuple Shuffle Expressions by CodaFi · Pull Request #705 · apple/swift-evolution · GitHub.

Thanks!

~Robert Widmann

[codafi (Robert Widmann)]

- Parse: Has to account for the inclusion of tuple shuffles whenever it parses patterns (see the switch-statement example in the proposal)
- Sema: Has to perform argument matching by computing these tuple shuffle mappings thereby complicating the solver and the parts of solution application. Really, the only place this has a valid use is in the error handling path where we can use the tuple shuffle to emit a fixit that properly reorders arguments - something we should be doing even today <https://bugs.swift.org/browse/SR-4715&gt;\. Tuple shuffles are also allowed to reorder around variadic arguments which makes matching that much more difficult.
- SIL: Has to account for tuple shuffles in multiple places. One notable one is that SILGen has to support two different paths when lowering tuple shuffles - one for variadic shuffles and the other for “normal” shuffles. Each path supports a different subset of the features necessary to implement the full feature that is tuple shuffles, neither can really be simplified down to a common core in their current iteration.

If you want some numbers, I spent the evening removing them from the codebase and came up with a win of about 1500 LoC. Each line of code supporting a feature that people aren’t actually using.

~Robert Widmann

···

On May 4, 2017, at 10:35 PM, Tony Arnold via swift-evolution <swift-evolution@swift.org> wrote:

On 5 May 2017, at 12:27, Félix Cloutier via swift-evolution <swift-evolution@swift.org> wrote:

Why?

Not trying to be smart, but the reasoning is in Robert’s proposal:

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), and makes non-sensical patterns possible in surprising places.

Robert, maybe you could include some detail about how this feature is complicating the compiler stack, and what will be improved by it’s removal?

====

That being said, I’m all for you guys making your lives easier at the cost of something we shouldn’t be using in the first place…

Tony

----------
Tony Arnold
+61 411 268 532
http://thecocoabots.com/

ABN: 14831833541

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[codafi (Robert Widmann)]

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@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@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.

Thanks!

~Robert Widmann

Deprecate Tuple Shuffles
Proposal: SE-NNNN
Authors: Robert Widmann
Review Manager: TBD
Status: Awaiting review
Introduction

This proposal seeks the deprecation of a little-known feature of Swift called a "Tuple Shuffle".

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, contradicts the goals of earlier SE's (see SE-0060), 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.

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.

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
Impact on Existing Code

Because very little code is intentionally using Tuple Shuffles, impact on existing code will be negligible but not non-zero.

Alternatives considered

Continue to keep the architecture in place to facilitate this feature.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[codafi (Robert Widmann)]

None of those are affected. See the note in the proposal.

~Robert Widmann

···

On May 5, 2017, at 1:16 AM, Adrian Zubarev <adrian.zubarev@devandartist.com> wrote:

Hi Robert,

I’m trying to understand the impact of your proposal and the feature you want to remove from the language. Could you describe a little more on how if ever this affects tuple destructuring?

var (a, b, c) = (0, "", 0)

(a, b) = (42, "Hello Swift")

(a = 42, b = "Hello Swift")

var (x, y) = (0, 42)

(x, y) = (y, x) // swap without a temporary value

--
Adrian Zubarev
Sent with Airmail

Am 5. Mai 2017 um 04:15:12, Robert Widmann via swift-evolution (swift-evolution@swift.org <mailto:swift-evolution@swift.org>) schrieb:

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 <[Proposal] Deprecate Tuple Shuffle Expressions by CodaFi · Pull Request #705 · apple/swift-evolution · GitHub.

Thanks!

~Robert Widmann

Deprecate Tuple Shuffles
Proposal: SE-NNNN <https://github.com/CodaFi/swift-evolution/blob/8eaf320b3c2a117909fc0269c398e89c033a4b9f/proposals/NNNN-filename.md&gt;
Authors: Robert Widmann <https://github.com/codafi&gt;
Review Manager: TBD
Status: Awaiting review
<https://github.com/CodaFi/swift-evolution/blob/8eaf320b3c2a117909fc0269c398e89c033a4b9f/proposals/NNNN-deprecate-tuple-shuffles.md#introduction&gt;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&gt;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&gt;, contradicts the goals of earlier SE's (see SE-0060 <https://github.com/apple/swift-evolution/blob/9cf2685293108ea3efcbebb7ee6a8618b83d4a90/proposals/0060-defaulted-parameter-order.md&gt;\), 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&gt;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&gt;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&gt;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&gt;Alternatives considered

Continue to keep the architecture in place to facilitate this feature.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

[xwu (Xiaodi Wu)]

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@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@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@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 <[Proposal] Deprecate Tuple Shuffle Expressions by CodaFi · Pull Request #705 · apple/swift-evolution · GitHub.

Thanks!

~Robert Widmann

Deprecate Tuple Shuffles

   - Proposal: SE-NNNN
   <https://github.com/CodaFi/swift-evolution/blob/8eaf320b3c2a117909fc0269c398e89c033a4b9f/proposals/NNNN-filename.md&gt;
   - Authors: Robert Widmann <https://github.com/codafi&gt;
   - Review Manager: TBD
   - Status: Awaiting review

<https://github.com/CodaFi/swift-evolution/blob/8eaf320b3c2a117909fc0269c398e89c033a4b9f/proposals/NNNN-deprecate-tuple-shuffles.md#introduction&gt;
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&gt;
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&gt;, contradicts the
goals of earlier SE's (see SE-0060
<https://github.com/apple/swift-evolution/blob/9cf2685293108ea3efcbebb7ee6a8618b83d4a90/proposals/0060-defaulted-parameter-order.md&gt;\),
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&gt;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&gt;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&gt;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&gt;Alternatives
considered
Continue to keep the architecture in place to facilitate this feature.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[DevAndArtist (Adrian Meister)]

Okay now I see where this is going. So basically you want to mirror the behavior of function parameters into tuples.

You might want to be a little bit more explicit on types in your proposal to better understand the so called ‘tuple shuffle’.

let a: (x: Int, y: Int) = (x: 1, y: 2)
var b: (y: Int, x: Int) = a
a.x == b.x
a.y == b.y
Label swap (tuple shuffle) while destructuring:

let tuple: (first: Int, second: (x: Int, y: Int)) = (first: 0, second: (x: 1, y: 2))

let (first: a, second: (x: b, y: c)): (first: Int, second: (x: Int, y: Int)) = tuple // fine, unaffected

let (second: (x: b, y: c), first: a): (second: (x: Int, y: Int), first: Int) = tuple // shuffle => error

···

--
Adrian Zubarev
Sent with Airmail

Am 5. Mai 2017 um 07:18:37, Robert Widmann (devteam.codafi@gmail.com) schrieb:

None of those are affected. See the note in the proposal.

~Robert Widmann

On May 5, 2017, at 1:16 AM, Adrian Zubarev <adrian.zubarev@devandartist.com> wrote:

Hi Robert,

I’m trying to understand the impact of your proposal and the feature you want to remove from the language. Could you describe a little more on how if ever this affects tuple destructuring?

var (a, b, c) = (0, "", 0)

(a, b) = (42, "Hello Swift")

(a = 42, b = "Hello Swift")

var (x, y) = (0, 42)

(x, y) = (y, x) // swap without a temporary value

--
Adrian Zubarev
Sent with Airmail

Am 5. Mai 2017 um 04:15:12, Robert Widmann via swift-evolution (swift-evolution@swift.org) schrieb:

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.

Thanks!

~Robert Widmann

Deprecate Tuple Shuffles
Proposal: SE-NNNN
Authors: Robert Widmann
Review Manager: TBD
Status: Awaiting review
Introduction

This proposal seeks the deprecation of a little-known feature of Swift called a "Tuple Shuffle".

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, contradicts the goals of earlier SE's (see SE-0060), 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.

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.

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
Impact on Existing Code

Because very little code is intentionally using Tuple Shuffles, impact on existing code will be negligible but not non-zero.

Alternatives considered

Continue to keep the architecture in place to facilitate this feature.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[masters3d]

I can't think of a single time when I would need a tuple shuffle but I don't really work with tuples much. It would be great to hear other people's usage of this feature.
I did not know that types could be overloaded with values. That was very surprising to me. Honestly I think that is the issue here. Not sure what can be done about it.

let Int = 5 // works
let Void = "what?" // works.

Very interesting. Could some one clarify, why this is allowed? Isn't this is a bug we want to fix? At least by requiring a tilda like `Int`
And of course, you can't "overload" user defined type:
struct S {}
let S = 10 // Error: invalid redeclaration of ’S'

What version of swift are you using? Could it be a regression?

Welcome to Apple Swift version 3.1 (swiftlang-802.0.51 clang-802.0.41). Type :help for assistance.
  1> struct S {}
  2> let S = 10
S: Int = 10
  3> print(S)
error: repl.swift:3:7: error: ambiguous use of 'S'
print(S)
      ^

···

On May 5, 2017, at 8:34 AM, Vladimir.S <svabox@gmail.com> wrote:
On 05.05.2017 6:12, Jose Cheyo Jimenez via swift-evolution wrote:

On May 4, 2017, at 7:14 PM, Robert Widmann via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@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 <[Proposal] Deprecate Tuple Shuffle Expressions by CodaFi · Pull Request #705 · apple/swift-evolution · GitHub.

Thanks!

~Robert Widmann

Deprecate Tuple Shuffles

* Proposal: SE-NNNN
   <https://github.com/CodaFi/swift-evolution/blob/8eaf320b3c2a117909fc0269c398e89c033a4b9f/proposals/NNNN-filename.md&gt;
* Authors: Robert Widmann <https://github.com/codafi&gt;
* Review Manager: TBD
* Status: Awaiting review

   <https://github.com/CodaFi/swift-evolution/blob/8eaf320b3c2a117909fc0269c398e89c033a4b9f/proposals/NNNN-deprecate-tuple-shuffles.md#introduction&gt;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&gt;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&gt;, contradicts the goals of earlier SE's (see SE-0060 <https://github.com/apple/swift-evolution/blob/9cf2685293108ea3efcbebb7ee6a8618b83d4a90/proposals/0060-defaulted-parameter-order.md&gt;\), 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&gt;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&gt;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&gt;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&gt;Alternatives
   considered

Continue to keep the architecture in place to facilitate this feature.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[masters3d]

I filled a bug report. [SR-4811] Type's name can be assigned a value · Issue #47388 · apple/swift · GitHub

···

On May 5, 2017, at 9:38 AM, Jose Cheyo Jimenez <cheyo@masters3d.com> wrote:

On May 5, 2017, at 8:34 AM, Vladimir.S <svabox@gmail.com <mailto:svabox@gmail.com>> wrote:

On 05.05.2017 6:12, Jose Cheyo Jimenez via swift-evolution wrote:

I can't think of a single time when I would need a tuple shuffle but I don't really work with tuples much. It would be great to hear other people's usage of this feature.
I did not know that types could be overloaded with values. That was very surprising to me. Honestly I think that is the issue here. Not sure what can be done about it.

let Int = 5 // works
let Void = "what?" // works.

Very interesting. Could some one clarify, why this is allowed? Isn't this is a bug we want to fix? At least by requiring a tilda like `Int`
And of course, you can't "overload" user defined type:
struct S {}
let S = 10 // Error: invalid redeclaration of ’S'

What version of swift are you using? Could it be a regression?

Welcome to Apple Swift version 3.1 (swiftlang-802.0.51 clang-802.0.41). Type :help for assistance.
  1> struct S {}
  2> let S = 10
S: Int = 10
  3> print(S)
error: repl.swift:3:7: error: ambiguous use of 'S'
print(S)
      ^

On May 4, 2017, at 7:14 PM, Robert Widmann via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org> <mailto:swift-evolution@swift.org <mailto:swift-evolution@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 <[Proposal] Deprecate Tuple Shuffle Expressions by CodaFi · Pull Request #705 · apple/swift-evolution · GitHub.

Thanks!

~Robert Widmann

Deprecate Tuple Shuffles

* Proposal: SE-NNNN
   <https://github.com/CodaFi/swift-evolution/blob/8eaf320b3c2a117909fc0269c398e89c033a4b9f/proposals/NNNN-filename.md&gt;
* Authors: Robert Widmann <https://github.com/codafi&gt;
* Review Manager: TBD
* Status: Awaiting review

   <https://github.com/CodaFi/swift-evolution/blob/8eaf320b3c2a117909fc0269c398e89c033a4b9f/proposals/NNNN-deprecate-tuple-shuffles.md#introduction&gt;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&gt;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&gt;, contradicts the goals of earlier SE's (see SE-0060 <https://github.com/apple/swift-evolution/blob/9cf2685293108ea3efcbebb7ee6a8618b83d4a90/proposals/0060-defaulted-parameter-order.md&gt;\), 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&gt;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&gt;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&gt;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&gt;Alternatives
   considered

Continue to keep the architecture in place to facilitate this feature.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org> <mailto:swift-evolution@swift.org <mailto:swift-evolution@swift.org>>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

[DevAndArtist (Adrian Meister)]

You’ve got your manual reordering wrong:

let a = (x: 1, y: 2)
var b: (y:Int, x:Int)

b = a // warning
b = (x: a.x, y: a.y) // explicit, manual reordering
It should be:

b = (y: a.y, x: a.x) // explicit, manual reordering

···

--
Adrian Zubarev
Sent with Airmail

Am 5. Mai 2017 um 11:48:50, Haravikk via swift-evolution (swift-evolution@swift.org) schrieb:

let a = (x: 1, y: 2)
var b: (y:Int, x:Int)

b = a // warning
b = (x: a.x, y: a.y) // explicit, manual reordering

[John_McCall]

- Parse: Has to account for the inclusion of tuple shuffles whenever it parses patterns (see the switch-statement example in the proposal)

This example doesn't make any sense. Tuple shuffles are not responsible for the rule that you cannot match an unlabelled tuple with a labelled tuple pattern. I'm really not sure what you think this would do, anyway; it's not like tuple pattern element labels are lexically available.

- Sema: Has to perform argument matching by computing these tuple shuffle mappings thereby complicating the solver and the parts of solution application. Really, the only place this has a valid use is in the error handling path where we can use the tuple shuffle to emit a fixit that properly reorders arguments - something we should be doing even today <https://bugs.swift.org/browse/SR-4715&gt;\. Tuple shuffles are also allowed to reorder around variadic arguments which makes matching that much more difficult.

The type-checker doesn't have to do this with argument-matching. It might do it anyway, but it doesn't have to.

- SIL: Has to account for tuple shuffles in multiple places. One notable one is that SILGen has to support two different paths when lowering tuple shuffles - one for variadic shuffles and the other for “normal” shuffles. Each path supports a different subset of the features necessary to implement the full feature that is tuple shuffles, neither can really be simplified down to a common core in their current iteration.

Call argument emission needs to deal with something like this anyway. But yes, we could eliminate the redundant path for ordinary r-value tuple emission.

I'm not saying any of this to kill this proposal, just to clarify that the complexity costs aren't as high as you seem to be saying.

John.

···

On May 4, 2017, at 10:52 PM, Robert Widmann via swift-evolution <swift-evolution@swift.org> wrote:

If you want some numbers, I spent the evening removing them from the codebase and came up with a win of about 1500 LoC. Each line of code supporting a feature that people aren’t actually using.

~Robert Widmann

On May 4, 2017, at 10:35 PM, Tony Arnold via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On 5 May 2017, at 12:27, Félix Cloutier via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Why?

Not trying to be smart, but the reasoning is in Robert’s proposal:

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), and makes non-sensical patterns possible in surprising places.

Robert, maybe you could include some detail about how this feature is complicating the compiler stack, and what will be improved by it’s removal?

====

That being said, I’m all for you guys making your lives easier at the cost of something we shouldn’t be using in the first place…

Tony

----------
Tony Arnold
+61 411 268 532
http://thecocoabots.com/

ABN: 14831833541

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[Anders]

I don’t think overshadowing types defined in another module is an issue at all, in which case `Int` and `Void` belong to the Swift module.

Regards,
Anders

···

On 5 May 2017, at 11:34 PM, Vladimir.S via swift-evolution <swift-evolution@swift.org> wrote:

On 05.05.2017 6:12, Jose Cheyo Jimenez via swift-evolution wrote:

I can't think of a single time when I would need a tuple shuffle but I don't really work with tuples much. It would be great to hear other people's usage of this feature.
I did not know that types could be overloaded with values. That was very surprising to me. Honestly I think that is the issue here. Not sure what can be done about it.

let Int = 5 // works
let Void = "what?" // works.

Very interesting. Could some one clarify, why this is allowed? Isn't this is a bug we want to fix? At least by requiring a tilda like `Int`
And of course, you can't "overload" user defined type:
struct S {}
let S = 10 // Error: invalid redeclaration of 'S'

On May 4, 2017, at 7:14 PM, Robert Widmann via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@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 <[Proposal] Deprecate Tuple Shuffle Expressions by CodaFi · Pull Request #705 · apple/swift-evolution · GitHub.

Thanks!

~Robert Widmann

Deprecate Tuple Shuffles

* Proposal: SE-NNNN
   <https://github.com/CodaFi/swift-evolution/blob/8eaf320b3c2a117909fc0269c398e89c033a4b9f/proposals/NNNN-filename.md&gt;
* Authors: Robert Widmann <https://github.com/codafi&gt;
* Review Manager: TBD
* Status: Awaiting review

   <https://github.com/CodaFi/swift-evolution/blob/8eaf320b3c2a117909fc0269c398e89c033a4b9f/proposals/NNNN-deprecate-tuple-shuffles.md#introduction&gt;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&gt;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&gt;, contradicts the goals of earlier SE's (see SE-0060 <https://github.com/apple/swift-evolution/blob/9cf2685293108ea3efcbebb7ee6a8618b83d4a90/proposals/0060-defaulted-parameter-order.md&gt;\), 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&gt;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&gt;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&gt;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&gt;Alternatives
   considered

Continue to keep the architecture in place to facilitate this feature.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution