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

[Boris Wang via swift-evolution]

Thanks, I just got the point:
  This is a war between Smalltalk and the world.

In Smalltalk, function is not a type:
   function's signature include attributes name, but Type not,.
The method Smalltalk treat function, is opposite to the normal method human
see the world.
For exam:
   We just need known someone called Boris Wang, not Boris
Wang(attr1,attr2,,attr100)

So, the more features we borrowed from the other languages in the world,
the more conflicts triggered.
The more consistent we wanted from Swift, the more conflicts triggered.

Erica Sadun via swift-evolution 于2017年5月9日
周二02:42写道：

>
> 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 .
>
> Thanks!
>
> ~Robert Widmann
>
>
> 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
>
> ___
> 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

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

[Erica Sadun via swift-evolution]

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

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

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

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

[Vladimir.S via swift-evolution]

On 05.05.2017 19:38, Jose Cheyo Jimenez wrote:


On May 5, 2017, at 8:34 AM, Vladimir.S > 
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)
   ^



xcrun swift -version

Apple Swift version 3.1 (swiftlang-802.0.53 clang-802.0.42)
Target: x86_64-apple-macosx10.9

func test() {
let Int = 10  // no errors/warnings
print(Int)// no errors/warnings

struct S {}
let S = 10   Error: "Definition conflicts with previous value"
}






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

 * 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 

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

[Xiaodi Wu via swift-evolution]

On Mon, May 8, 2017 at 4:01 AM, André Videla  wrote:

> > Why do you feel this clever puzzle needs to be eliminated?
> I dont feel like it needs to be eliminated.
>
> > Do you have any evidence that this shows up in real-world code?
> No.
>
> > For instance, I have had to use the name `T` at one point, because I was
> modeling something where `t` means a totally different thing.
> Other programming language implement the "prime" notation for those cases.
> Capitalisation is not the only alternative. If you have four variables
> related to each others you'd have t, t', t'' and t''' . If you use capitals
> you would use t, T and TT? Tt? T1? the next ones are not very clear.
>

To be clear, I'm not talking about related variables. In that particular
use case, I was modeling a mathematical transformation with two unrelated
constants named `T` and `t`. The only suitable name for `T` is therefore
`T`, as it cannot be `t`. There are other physical and mathematical
constants that are always referred to by uppercase or lowercase Latin or
Greek letters, for example, where the letter with the opposite case refers
to a totally different constant. It is reasonable to permit these special
uses to capitalize as necessary for clarity.

> Consider also C interop issues.
> I have no idea of the complexity of such a task but there is already some
> identifiers transformations for Obj-C interop. Maybe this kind of
> transformation could work for C interop.
>
> > the same could not be enforced for CJK variable names and type names
> And emoji.
>
> > Robert has presented a clever puzzle, but it is confusing only because
> he has deliberately designed it to be a puzzle.
> You'd be surprised how many kids playing with Swift in playgrounds create
> intricate puzzles for themselves unintentionally.
>
>
> 2017-05-08 10:42 GMT+02:00 Xiaodi Wu :
>
>> On Mon, May 8, 2017 at 3:35 AM, André Videla 
>> wrote:
>>
>>> By the way, it seems that the only way to get rid of this clever puzzle
>>> is to enforce uppercase for the first letter of type identifiers and lower
>>> case for values identifiers.
>>>
>>
>> Why do you feel this clever puzzle needs to be eliminated? Do you have
>> any evidence that this shows up in real-world code? As I said before, my
>> analysis is that it will only be found in code if the writer is
>> intentionally trying to torture his or her reader, which is a fruitless
>> issue to prevent.
>>
>> The convention of using uppercase only for the first letter of types is
>> already well observed. However, there are legitimate reasons why someone
>> may choose to name a member with uppercase. For instance, I have had to use
>> the name `T` at one point, because I was modeling something where `t` means
>> a totally different thing. Mathematical constants tend to differ based on
>> case. Consider also C interop issues. Finally, this distinction becomes
>> meaningless in languages without case; the same could not be enforced for
>> CJK variable names and type names, for example. However, it is possible to
>> warn when a variable name shadows a type, and this could be useful. But,
>> before we go designing anything in this area, again, as I've already
>> written in this thread, there will already be many compiler warnings and
>> errors if someone makes this mistake unintentionally; Robert has presented
>> a clever puzzle, but it is confusing only because he has deliberately
>> designed it to be a puzzle.
>>
>>
>> 2017-05-08 10:24 GMT+02:00 Adrian Zubarev via swift-evolution <
>>> swift-evolution@swift.org>:
>>>
 I still have to disagree on that. Tuple patterns are not consistent in
 Swift.

 Here is a small proof of my claim:

 enum Foo {

 case a(b: Int)
 }

 switch Foo.a(b: 10) {

 case .a(b: let x):
 print(x)
 }

 let tuple = (x: 2, y:  20)

 switch tuple {

 case (x: let a, y: let b):
 print(a); print(b)
 }

 (x: let a, y: let b): (x: Int, y: Int) = tuple // Error!!!

 Tuple destructuring only works using the shorthand pattern, which _can_
 lead to all those puzzles from the discussion.
 --

 The shorthand form ‘Is good and beautiful’ (German proverb), but it can
 do more harm than it should. Personally I would entirely ban the shorthand
 version unless we’ve got a superior version of it without all these issues.
 --

 By the way not only tuples are affected by the mentioned puzzle:

 enum Foo {

 case sum(x: Int, y: Int)
 }

 switch Foo.sum(x: 3, y: 1) {

 case let .sum(x: Int, y: Double):
 print(Int + Double) // prints 4
 }



 --
 Adrian Zubarev
 Sent with Airmail

 Am 8. Mai 2017 um 09:28:52, Xiaodi Wu via swift-evolution (
 swift-evolution@swift.org) 

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

[Xiaodi Wu via swift-evolution]

On Mon, May 8, 2017 at 3:08 AM, Brent Royal-Gordon 
wrote:

> On May 8, 2017, at 12:09 AM, Xiaodi Wu  wrote:
>
> Highly disagree. Consistency teaches us that variables can come after a
> colon.
>
>
> But not normally in a declaration.
>
> On May 8, 2017, at 12:28 AM, Xiaodi Wu  wrote:
>
> Yes, Robert came up with a very clever puzzle. I'll bet you there are
> *plenty* of neat puzzles that you can come up with if you start naming your
> variables `Int` and `Double`.
>
>
> Sure, but how many of them look *so much* like a declaration that, even
> knowing there's a puzzle, you still don't guess what's going on? Because
> that was my experience with his "puzzle".
>

So, then, the puzzle puzzled you.

I know that Swift pattern matching is based on the idea that the pattern
> looks like the code used to construct the value it matches. But in the case
> of capturing values from labeled paren lists, I think it leads to deeply
> confusing code. We already knew about the weirdness of `as` in pattern
> matches, but this is even worse.
>
> I think we ought to reconsider what we're doing in this area, and perhaps
> move more towards a syntax that echoes declaration rather than use. When a
> piece of syntax *really* looks like it does A, even to experienced users,
> but it actually does B, that's a sign that it's the wrong syntax.
>

Again, if you were to write this piece of code yourself, a whole slew of
warnings would tell you unambiguously that it's B and not A. It would warn
you that `Int` and `Double` are never used before you even typed the second
line. If you tried to use `x` and `y`, it would error and tell you they've
not been declared. If the tuple had two homogeneous elements, it would have
given an error that you'd redeclared the same variable twice.

And if those aren't enough, it is possible to add warnings about variable
names that shadow type names (which may have broader benefits and is worth
consideration) and it is possible to add warnings when labels are used to
destructure a tuple that doesn't come with its own labels.

To demonstrate where the puzzle ended up being very clever, consider this
one-liner:

```
print(Int + Double) // Prints "4".
```

This alone will *really* look like something it is not even to experienced
users; it involves no tuples or pattern matching. (Interestingly, without
an implementation of the proposal accepted long ago to remove `.self` from
the language, one actually cannot make this happen in the following way; in
other words, `Int` and `Double` in that context currently _cannot_ be
types.)

```
func + (_: T.Type, _: U.Type) -> Int { return 4 }
// However, one must write `Int.self + Double.self`
```

But in any case, the original point I was making in response to Robert's
original proposal is that getting rid of tuple shuffles is a topic that's
orthogonal to pattern matching syntax. If you want to redesign all of
pattern matching syntax for Swift, that's a conversation for another day.
Just note that `if/for/while let` syntax went through a controversial
overhaul for Swift 3, and a proposal to change enum case pattern matching
only just got accepted with revisions last month and hasn't even been
implemented yet for Swift 4. This is getting very near access modifiers in
terms of churn during every release of Swift.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[André Videla via swift-evolution]

> Why do you feel this clever puzzle needs to be eliminated?
I dont feel like it needs to be eliminated.

> Do you have any evidence that this shows up in real-world code?
No.

> For instance, I have had to use the name `T` at one point, because I was
modeling something where `t` means a totally different thing.
Other programming language implement the "prime" notation for those cases.
Capitalisation is not the only alternative. If you have four variables
related to each others you'd have t, t', t'' and t''' . If you use capitals
you would use t, T and TT? Tt? T1? the next ones are not very clear.

> Consider also C interop issues.
I have no idea of the complexity of such a task but there is already some
identifiers transformations for Obj-C interop. Maybe this kind of
transformation could work for C interop.

> the same could not be enforced for CJK variable names and type names
And emoji.

> Robert has presented a clever puzzle, but it is confusing only because he
has deliberately designed it to be a puzzle.
You'd be surprised how many kids playing with Swift in playgrounds create
intricate puzzles for themselves unintentionally.


2017-05-08 10:42 GMT+02:00 Xiaodi Wu :

> On Mon, May 8, 2017 at 3:35 AM, André Videla 
> wrote:
>
>> By the way, it seems that the only way to get rid of this clever puzzle
>> is to enforce uppercase for the first letter of type identifiers and lower
>> case for values identifiers.
>>
>
> Why do you feel this clever puzzle needs to be eliminated? Do you have any
> evidence that this shows up in real-world code? As I said before, my
> analysis is that it will only be found in code if the writer is
> intentionally trying to torture his or her reader, which is a fruitless
> issue to prevent.
>
> The convention of using uppercase only for the first letter of types is
> already well observed. However, there are legitimate reasons why someone
> may choose to name a member with uppercase. For instance, I have had to use
> the name `T` at one point, because I was modeling something where `t` means
> a totally different thing. Mathematical constants tend to differ based on
> case. Consider also C interop issues. Finally, this distinction becomes
> meaningless in languages without case; the same could not be enforced for
> CJK variable names and type names, for example. However, it is possible to
> warn when a variable name shadows a type, and this could be useful. But,
> before we go designing anything in this area, again, as I've already
> written in this thread, there will already be many compiler warnings and
> errors if someone makes this mistake unintentionally; Robert has presented
> a clever puzzle, but it is confusing only because he has deliberately
> designed it to be a puzzle.
>
>
> 2017-05-08 10:24 GMT+02:00 Adrian Zubarev via swift-evolution <
>> swift-evolution@swift.org>:
>>
>>> I still have to disagree on that. Tuple patterns are not consistent in
>>> Swift.
>>>
>>> Here is a small proof of my claim:
>>>
>>> enum Foo {
>>>
>>> case a(b: Int)
>>> }
>>>
>>> switch Foo.a(b: 10) {
>>>
>>> case .a(b: let x):
>>> print(x)
>>> }
>>>
>>> let tuple = (x: 2, y:  20)
>>>
>>> switch tuple {
>>>
>>> case (x: let a, y: let b):
>>> print(a); print(b)
>>> }
>>>
>>> (x: let a, y: let b): (x: Int, y: Int) = tuple // Error!!!
>>>
>>> Tuple destructuring only works using the shorthand pattern, which _can_
>>> lead to all those puzzles from the discussion.
>>> --
>>>
>>> The shorthand form ‘Is good and beautiful’ (German proverb), but it can
>>> do more harm than it should. Personally I would entirely ban the shorthand
>>> version unless we’ve got a superior version of it without all these issues.
>>> --
>>>
>>> By the way not only tuples are affected by the mentioned puzzle:
>>>
>>> enum Foo {
>>>
>>> case sum(x: Int, y: Int)
>>> }
>>>
>>> switch Foo.sum(x: 3, y: 1) {
>>>
>>> case let .sum(x: Int, y: Double):
>>> print(Int + Double) // prints 4
>>> }
>>>
>>>
>>>
>>> --
>>> Adrian Zubarev
>>> Sent with Airmail
>>>
>>> Am 8. Mai 2017 um 09:28:52, Xiaodi Wu via swift-evolution (
>>> swift-evolution@swift.org) schrieb:
>>>
>>> But, in any case, with respect to consistency with the rest of the
>>> language, tuple patterns with labels are *supremely* consistent.
>>>
>>>
>>> ___
>>> 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

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

[Xiaodi Wu via swift-evolution]

On Mon, May 8, 2017 at 3:35 AM, André Videla  wrote:

> By the way, it seems that the only way to get rid of this clever puzzle is
> to enforce uppercase for the first letter of type identifiers and lower
> case for values identifiers.
>

Why do you feel this clever puzzle needs to be eliminated? Do you have any
evidence that this shows up in real-world code? As I said before, my
analysis is that it will only be found in code if the writer is
intentionally trying to torture his or her reader, which is a fruitless
issue to prevent.

The convention of using uppercase only for the first letter of types is
already well observed. However, there are legitimate reasons why someone
may choose to name a member with uppercase. For instance, I have had to use
the name `T` at one point, because I was modeling something where `t` means
a totally different thing. Mathematical constants tend to differ based on
case. Consider also C interop issues. Finally, this distinction becomes
meaningless in languages without case; the same could not be enforced for
CJK variable names and type names, for example. However, it is possible to
warn when a variable name shadows a type, and this could be useful. But,
before we go designing anything in this area, again, as I've already
written in this thread, there will already be many compiler warnings and
errors if someone makes this mistake unintentionally; Robert has presented
a clever puzzle, but it is confusing only because he has deliberately
designed it to be a puzzle.


2017-05-08 10:24 GMT+02:00 Adrian Zubarev via swift-evolution <
> swift-evolution@swift.org>:
>
>> I still have to disagree on that. Tuple patterns are not consistent in
>> Swift.
>>
>> Here is a small proof of my claim:
>>
>> enum Foo {
>>
>> case a(b: Int)
>> }
>>
>> switch Foo.a(b: 10) {
>>
>> case .a(b: let x):
>> print(x)
>> }
>>
>> let tuple = (x: 2, y:  20)
>>
>> switch tuple {
>>
>> case (x: let a, y: let b):
>> print(a); print(b)
>> }
>>
>> (x: let a, y: let b): (x: Int, y: Int) = tuple // Error!!!
>>
>> Tuple destructuring only works using the shorthand pattern, which _can_
>> lead to all those puzzles from the discussion.
>> --
>>
>> The shorthand form ‘Is good and beautiful’ (German proverb), but it can
>> do more harm than it should. Personally I would entirely ban the shorthand
>> version unless we’ve got a superior version of it without all these issues.
>> --
>>
>> By the way not only tuples are affected by the mentioned puzzle:
>>
>> enum Foo {
>>
>> case sum(x: Int, y: Int)
>> }
>>
>> switch Foo.sum(x: 3, y: 1) {
>>
>> case let .sum(x: Int, y: Double):
>> print(Int + Double) // prints 4
>> }
>>
>>
>>
>> --
>> Adrian Zubarev
>> Sent with Airmail
>>
>> Am 8. Mai 2017 um 09:28:52, Xiaodi Wu via swift-evolution (
>> swift-evolution@swift.org) schrieb:
>>
>> But, in any case, with respect to consistency with the rest of the
>> language, tuple patterns with labels are *supremely* consistent.
>>
>>
>> ___
>> 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

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

[Xiaodi Wu via swift-evolution]

On Mon, May 8, 2017 at 2:51 AM, André Videla  wrote:

> Let me show you:
>
> assume we have this data type which is just a pair of Ints
>
> enum Pair {
>
> case point(x: Int, y: Int)
>
> }
>
> and see how Swift allows us to deconstruct it:
>
> if case .point(let x, let y) = Pair.point(x: 3, y: 5) {
>
> print("\(x), \(y)")
>
> }
>
> this is perfectly fine. Even if the labels are omitted the structure is
> kept and x = 3 and y = 5
>
> if case .point(x: let x, y: let y) = Pair.point(x: 3, y: 5) {
>
> print("\(x), \(y)")
>
> }
>
> perfectly fine, x and y are given and correspond to the actual label of
> the enum case x = 3, y = 5
>
>
> if case .point(y: let x, x: let y) = Pair.point(x: 3, y: 5) {
>
> print("\(x), \(y)")
>
> }
>
> This is an error, as expected, labels do not correspond to any existing
> known structure and the match makes no sense. It does not compile
>
> Now we refactor the code a bit and we start using a pair instead of an
> enum  case
>
> if case (let x, let y) = (x: 3, y: 5) {
>
> print("\(x), \(y)")
>
> }
>
> this is fine since the structure is preserved from the value on the right,
> x = 3, y = 5
>
> if case (x: let x, y: let y) = (x: 3, y: 5) {
>
> print("\(x), \(y)")
>
> }
>
> this is fine since the labels correspond to the existing structure on the
> right x = 3, y = 5
>
> if case (y: let x, x: let y) = (x: 3, y: 5) {
>
> print("\(x), \(y)")
>
> }
>
> And this.
>
> This compiles even though the *structure matched does not correspond to
> the structure of the value against which it matches*.  x = 5, y = 3
>
Yes, and Robert is proposing to eliminate tuple shuffles from the language;
if accepted, then this last example will behave differently.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[André Videla via swift-evolution]

By the way, it seems that the only way to get rid of this clever puzzle is
to enforce uppercase for the first letter of type identifiers and lower
case for values identifiers.

2017-05-08 10:24 GMT+02:00 Adrian Zubarev via swift-evolution <
swift-evolution@swift.org>:

> I still have to disagree on that. Tuple patterns are not consistent in
> Swift.
>
> Here is a small proof of my claim:
>
> enum Foo {
>
> case a(b: Int)
> }
>
> switch Foo.a(b: 10) {
>
> case .a(b: let x):
> print(x)
> }
>
> let tuple = (x: 2, y:  20)
>
> switch tuple {
>
> case (x: let a, y: let b):
> print(a); print(b)
> }
>
> (x: let a, y: let b): (x: Int, y: Int) = tuple // Error!!!
>
> Tuple destructuring only works using the shorthand pattern, which _can_
> lead to all those puzzles from the discussion.
> --
>
> The shorthand form ‘Is good and beautiful’ (German proverb), but it can do
> more harm than it should. Personally I would entirely ban the shorthand
> version unless we’ve got a superior version of it without all these issues.
> --
>
> By the way not only tuples are affected by the mentioned puzzle:
>
> enum Foo {
>
> case sum(x: Int, y: Int)
> }
>
> switch Foo.sum(x: 3, y: 1) {
>
> case let .sum(x: Int, y: Double):
> print(Int + Double) // prints 4
> }
>
>
>
> --
> Adrian Zubarev
> Sent with Airmail
>
> Am 8. Mai 2017 um 09:28:52, Xiaodi Wu via swift-evolution (
> swift-evolution@swift.org) schrieb:
>
> But, in any case, with respect to consistency with the rest of the
> language, tuple patterns with labels are *supremely* consistent.
>
>
> ___
> 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

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

[Adrian Zubarev via swift-evolution]

I still have to disagree on that. Tuple patterns are not consistent in Swift.

Here is a small proof of my claim:

enum Foo {
 
case a(b: Int)
}

switch Foo.a(b: 10) {
 
case .a(b: let x):
print(x)
}

let tuple = (x: 2, y:  20)

switch tuple {
 
case (x: let a, y: let b):
print(a); print(b)
}

(x: let a, y: let b): (x: Int, y: Int) = tuple // Error!!!
Tuple destructuring only works using the shorthand pattern, which _can_ lead to 
all those puzzles from the discussion.

The shorthand form ‘Is good and beautiful’ (German proverb), but it can do more 
harm than it should. Personally I would entirely ban the shorthand version 
unless we’ve got a superior version of it without all these issues.

By the way not only tuples are affected by the mentioned puzzle:

enum Foo {
 
case sum(x: Int, y: Int)
}

switch Foo.sum(x: 3, y: 1) {
 
case let .sum(x: Int, y: Double):
print(Int + Double) // prints 4
}


-- 
Adrian Zubarev
Sent with Airmail

Am 8. Mai 2017 um 09:28:52, Xiaodi Wu via swift-evolution 
(swift-evolution@swift.org) schrieb:

But, in any case, with respect to consistency with the rest of the language, 
tuple patterns with labels are *supremely* consistent.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Brent Royal-Gordon via swift-evolution]

> On May 8, 2017, at 12:09 AM, Xiaodi Wu  wrote:
> 
> Highly disagree. Consistency teaches us that variables can come after a colon.

But not normally in a declaration.

> On May 8, 2017, at 12:28 AM, Xiaodi Wu  wrote:
> 
> Yes, Robert came up with a very clever puzzle. I'll bet you there are 
> *plenty* of neat puzzles that you can come up with if you start naming your 
> variables `Int` and `Double`.

Sure, but how many of them look *so much* like a declaration that, even knowing 
there's a puzzle, you still don't guess what's going on? Because that was my 
experience with his "puzzle".

I know that Swift pattern matching is based on the idea that the pattern looks 
like the code used to construct the value it matches. But in the case of 
capturing values from labeled paren lists, I think it leads to deeply confusing 
code. We already knew about the weirdness of `as` in pattern matches, but this 
is even worse.

I think we ought to reconsider what we're doing in this area, and perhaps move 
more towards a syntax that echoes declaration rather than use. When a piece of 
syntax *really* looks like it does A, even to experienced users, but it 
actually does B, that's a sign that it's the wrong syntax.

-- 
Brent Royal-Gordon
Architechies

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

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

[Xiaodi Wu via swift-evolution]

On Mon, May 8, 2017 at 2:15 AM, David Hart  wrote:

>
> On 8 May 2017, at 09:09, Xiaodi Wu  wrote:
>
> On Mon, May 8, 2017 at 12:16 AM, David Hart  wrote:
>
>>
>> On 7 May 2017, at 00:21, Xiaodi Wu via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> To which human would it be misleading?
>>
>> To the writer? No, because the compiler will warn you right away. By the
>> time you're done with writing the first line, it'll warn you that Int and
>> Double are unused variables. And if you try to use x and y, you get an
>> error.
>>
>> To the reader? Only if the writer knowingly wrote this misleading code.
>> In other words, it's a nice puzzle, but no reader will encounter this in
>> real-world code, unless they're being tormented by the writer on purpose.
>>
>>
>> IMHO, the fact that the compiler warns you does no change the fact that
>> it's a very confusing part of the language. It should not be an excuse for
>> fixing it. Consistency teaches us to expect a type after a colon.
>>
>
> Highly disagree. Consistency teaches us that variables can come after a
> colon.
>
>
> Correct. I meant to say that sentence in the context of the LHS of an
> assignment.
>

As Adrian shows, enum case patterns have the exact same syntax during
pattern matching, and you'll find the variable that's being bound written
after a colon on the LHS:

```
enum Foo { case bar, baz(boo: Int) }

let foo = Foo.baz(boo: 42)

if case let .baz(boo: x) = foo {
  print(x) // Prints "42".
}
```

There's a longstanding complaint that pattern matching in Swift is
backwards in terms of what's on the LHS and what's on the RHS. Recall the
numerous proposals on the list to introduce a `=~` operator that reverses
LHS and RHS as compared to the current `~=`. (IIRC, the core team responded
to say that they had tried it both ways and the current sequence was the
more ergonomic of the two.) But, in any case, with respect to consistency
with the rest of the language, tuple patterns with labels are *supremely*
consistent.

Can’t we even agree that the syntax is misleading?
>

No! Until this conversation I would have laughed at the suggestion that
*anyone* would find this even slightly misleading. Yes, Robert came up with
a very clever puzzle. I'll bet you there are *plenty* of neat puzzles that
you can come up with if you start naming your variables `Int` and `Double`.
That does _not_ demonstrate that tuple patterns are misleading.


> ```
> func foo(bar: Int, baz: Int) {
>   print(bar, baz)
> }
>
> func foo(bar: Bool, baz: Bool) {
>   print(bar, baz)
> }
>
> let x = 42
> let y = 43
> foo(bar: x, baz: y)
> // x and y are variables, and they come after the colon.
> // We don't allow users to write `foo(bar x: Int, baz y: Int)`,
> // even when there are overloads.
> ```
>
> There is nothing inconsistent about this part of the language.
>
>
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Xiaodi Wu via swift-evolution]

On Mon, May 8, 2017 at 1:30 AM, Adrian Zubarev via swift-evolution <
swift-evolution@swift.org> wrote:

> Exactly, everything else is simply an excuse and nothing more. Tuple
> destructuring is not even aligned to enum case patterns at all, because it
> only uses the shorthand version and does not allow us to write the full
> explicit version.
>
> enum Foo { case a(b: Int, c: Int) }
>
> switch Foo.a(b: 42, c: 0) {
> case let .a(b: num1, c: num2): …
>
>
You've just demonstrated how enum case patterns align with tuple patterns.
This is exactly the same syntax. Here, too, no type is allowed after the
colon. In fact, during discussion about allowing cases with the same base
name, it was shown that overloading cases would be tricky precisely because
of this: you're not allowed to disambiguate by writing `case let .a(b:
num1: Int, c: num2: Int)` if two cases differ only by the type of their
arguments.

>
>
> // Or the explicit longer version:
> case .a(b: let num1, c: let: num2): …
> }
>
> Tuple destructuring do not support the latter, which in our previous
> example would really be unambiguous.
>
> let tuple: (x: Int, y: Int) = (3, 1)
>
> // Short version:
> let (x: Int, y: Double): (x: Int, y: Int) = tuple
>
> // Not supported explicit version:
> (x: let Int, y: let Double) = tuple
>
> Why is that the case? Because tuple destructuring creates another tuple on
> the left side of the same tuple type as the tuple on the right side of the
> assignment operator.
>

I see no reason why that syntax could not also be supported, other than
that there's no demand for it.


> Erica Sudan has a proposal, which could change that for guards and ifs
> (second design): https://github.com/erica/swift-evolution/blob/
> 783fdf8d3723d51f350b917af23c207cebdd1ad7/proposals/-ifcaseguardcase.md
>
>
>
> --
> Adrian Zubarev
> Sent with Airmail
>
> Am 8. Mai 2017 um 07:16:50, David Hart via swift-evolution (
> swift-evolution@swift.org) schrieb:
>
>
> On 7 May 2017, at 00:21, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> To which human would it be misleading?
>
> To the writer? No, because the compiler will warn you right away. By the
> time you're done with writing the first line, it'll warn you that Int and
> Double are unused variables. And if you try to use x and y, you get an
> error.
>
> To the reader? Only if the writer knowingly wrote this misleading code. In
> other words, it's a nice puzzle, but no reader will encounter this in
> real-world code, unless they're being tormented by the writer on purpose.
>
>
> IMHO, the fact that the compiler warns you does no change the fact that
> it's a very confusing part of the language. It should not be an excuse for
> fixing it. Consistency teaches us to expect a type after a colon.
>
> On Sat, May 6, 2017 at 16:28 Brent Royal-Gordon 
> wrote:
>
>> > On May 5, 2017, at 11:06 PM, Xiaodi Wu  wrote:
>> >
>> > The identifier after a colon is *never* a type in any pattern matching,
>> and there's no need of which I'm aware to support type annotations in
>> pattern matching. We put colons after labels, and the current syntax is
>> perfectly consistent here. What is the defect you're trying to cure?
>>
>> The defect underlying this proposal: `let (x: Int, y: Double)` looks like
>> it's declaring `x` and `y` of types `Int` and `Double`, but it's actually
>> declaring `Int` and `Double` and binding them to `x` and `y`. Your code's
>> meaning is perfectly unambiguous to the compiler, of course, but it's
>> misleading to the human.
>>
>> --
>> Brent Royal-Gordon
>> Architechies
>>
>> ___
> 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
>
>
> ___
> 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

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

[David Hart via swift-evolution]

> On 8 May 2017, at 09:09, Xiaodi Wu  wrote:
> 
> On Mon, May 8, 2017 at 12:16 AM, David Hart  > wrote:
> 
> On 7 May 2017, at 00:21, Xiaodi Wu via swift-evolution 
> > wrote:
> 
>> To which human would it be misleading?
>> 
>> To the writer? No, because the compiler will warn you right away. By the 
>> time you're done with writing the first line, it'll warn you that Int and 
>> Double are unused variables. And if you try to use x and y, you get an error.
>> 
>> To the reader? Only if the writer knowingly wrote this misleading code. In 
>> other words, it's a nice puzzle, but no reader will encounter this in 
>> real-world code, unless they're being tormented by the writer on purpose.
> 
> IMHO, the fact that the compiler warns you does no change the fact that it's 
> a very confusing part of the language. It should not be an excuse for fixing 
> it. Consistency teaches us to expect a type after a colon.
> 
> Highly disagree. Consistency teaches us that variables can come after a colon.

Correct. I meant to say that sentence in the context of the LHS of an 
assignment. Can’t we even agree that the syntax is misleading?

> ```
> func foo(bar: Int, baz: Int) {
>   print(bar, baz)
> }
> 
> func foo(bar: Bool, baz: Bool) {
>   print(bar, baz)
> }
> 
> let x = 42
> let y = 43
> foo(bar: x, baz: y)
> // x and y are variables, and they come after the colon.
> // We don't allow users to write `foo(bar x: Int, baz y: Int)`,
> // even when there are overloads.
> ```
> 
> There is nothing inconsistent about this part of the language.
> 
> 

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

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

[Xiaodi Wu via swift-evolution]

On Mon, May 8, 2017 at 12:16 AM, David Hart  wrote:

>
> On 7 May 2017, at 00:21, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> To which human would it be misleading?
>
> To the writer? No, because the compiler will warn you right away. By the
> time you're done with writing the first line, it'll warn you that Int and
> Double are unused variables. And if you try to use x and y, you get an
> error.
>
> To the reader? Only if the writer knowingly wrote this misleading code. In
> other words, it's a nice puzzle, but no reader will encounter this in
> real-world code, unless they're being tormented by the writer on purpose.
>
>
> IMHO, the fact that the compiler warns you does no change the fact that
> it's a very confusing part of the language. It should not be an excuse for
> fixing it. Consistency teaches us to expect a type after a colon.
>

Highly disagree. Consistency teaches us that variables can come after a
colon.

```
func foo(bar: Int, baz: Int) {
  print(bar, baz)
}

func foo(bar: Bool, baz: Bool) {
  print(bar, baz)
}

let x = 42
let y = 43
foo(bar: x, baz: y)
// x and y are variables, and they come after the colon.
// We don't allow users to write `foo(bar x: Int, baz y: Int)`,
// even when there are overloads.
```

There is nothing inconsistent about this part of the language.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Adrian Zubarev via swift-evolution]

Exactly, everything else is simply an excuse and nothing more. Tuple 
destructuring is not even aligned to enum case patterns at all, because it only 
uses the shorthand version and does not allow us to write the full explicit 
version.

enum Foo { case a(b: Int, c: Int) }

switch Foo.a(b: 42, c: 0) {
case let .a(b: num1, c: num2): …
 
// Or the explicit longer version:
case .a(b: let num1, c: let: num2): …
}
Tuple destructuring do not support the latter, which in our previous example 
would really be unambiguous.

let tuple: (x: Int, y: Int) = (3, 1)

// Short version:
let (x: Int, y: Double): (x: Int, y: Int) = tuple

// Not supported explicit version:
(x: let Int, y: let Double) = tuple
Why is that the case? Because tuple destructuring creates another tuple on the 
left side of the same tuple type as the tuple on the right side of the 
assignment operator.

Erica Sudan has a proposal, which could change that for guards and ifs (second 
design): 
https://github.com/erica/swift-evolution/blob/783fdf8d3723d51f350b917af23c207cebdd1ad7/proposals/-ifcaseguardcase.md



-- 
Adrian Zubarev
Sent with Airmail

Am 8. Mai 2017 um 07:16:50, David Hart via swift-evolution 
(swift-evolution@swift.org) schrieb:


On 7 May 2017, at 00:21, Xiaodi Wu via swift-evolution 
 wrote:

To which human would it be misleading?

To the writer? No, because the compiler will warn you right away. By the time 
you're done with writing the first line, it'll warn you that Int and Double are 
unused variables. And if you try to use x and y, you get an error.

To the reader? Only if the writer knowingly wrote this misleading code. In 
other words, it's a nice puzzle, but no reader will encounter this in 
real-world code, unless they're being tormented by the writer on purpose.

IMHO, the fact that the compiler warns you does no change the fact that it's a 
very confusing part of the language. It should not be an excuse for fixing it. 
Consistency teaches us to expect a type after a colon.

On Sat, May 6, 2017 at 16:28 Brent Royal-Gordon  wrote:
> On May 5, 2017, at 11:06 PM, Xiaodi Wu  wrote:
>
> The identifier after a colon is *never* a type in any pattern matching, and 
> there's no need of which I'm aware to support type annotations in pattern 
> matching. We put colons after labels, and the current syntax is perfectly 
> consistent here. What is the defect you're trying to cure?

The defect underlying this proposal: `let (x: Int, y: Double)` looks like it's 
declaring `x` and `y` of types `Int` and `Double`, but it's actually declaring 
`Int` and `Double` and binding them to `x` and `y`. Your code's meaning is 
perfectly unambiguous to the compiler, of course, but it's misleading to the 
human.

--
Brent Royal-Gordon
Architechies

___
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
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[David Hart via swift-evolution]

> On 7 May 2017, at 00:21, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> To which human would it be misleading?
> 
> To the writer? No, because the compiler will warn you right away. By the time 
> you're done with writing the first line, it'll warn you that Int and Double 
> are unused variables. And if you try to use x and y, you get an error.
> 
> To the reader? Only if the writer knowingly wrote this misleading code. In 
> other words, it's a nice puzzle, but no reader will encounter this in 
> real-world code, unless they're being tormented by the writer on purpose.

IMHO, the fact that the compiler warns you does no change the fact that it's a 
very confusing part of the language. It should not be an excuse for fixing it. 
Consistency teaches us to expect a type after a colon.

>> On Sat, May 6, 2017 at 16:28 Brent Royal-Gordon  
>> wrote:
>> > On May 5, 2017, at 11:06 PM, Xiaodi Wu  wrote:
>> >
>> > The identifier after a colon is *never* a type in any pattern matching, 
>> > and there's no need of which I'm aware to support type annotations in 
>> > pattern matching. We put colons after labels, and the current syntax is 
>> > perfectly consistent here. What is the defect you're trying to cure?
>> 
>> The defect underlying this proposal: `let (x: Int, y: Double)` looks like 
>> it's declaring `x` and `y` of types `Int` and `Double`, but it's actually 
>> declaring `Int` and `Double` and binding them to `x` and `y`. Your code's 
>> meaning is perfectly unambiguous to the compiler, of course, but it's 
>> misleading to the human.
>> 
>> --
>> Brent Royal-Gordon
>> Architechies
>> 
> ___
> 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

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

[Xiaodi Wu via swift-evolution]

To which human would it be misleading?

To the writer? No, because the compiler will warn you right away. By the
time you're done with writing the first line, it'll warn you that Int and
Double are unused variables. And if you try to use x and y, you get an
error.

To the reader? Only if the writer knowingly wrote this misleading code. In
other words, it's a nice puzzle, but no reader will encounter this in
real-world code, unless they're being tormented by the writer on purpose.
On Sat, May 6, 2017 at 16:28 Brent Royal-Gordon 
wrote:

> > On May 5, 2017, at 11:06 PM, Xiaodi Wu  wrote:
> >
> > The identifier after a colon is *never* a type in any pattern matching,
> and there's no need of which I'm aware to support type annotations in
> pattern matching. We put colons after labels, and the current syntax is
> perfectly consistent here. What is the defect you're trying to cure?
>
> The defect underlying this proposal: `let (x: Int, y: Double)` looks like
> it's declaring `x` and `y` of types `Int` and `Double`, but it's actually
> declaring `Int` and `Double` and binding them to `x` and `y`. Your code's
> meaning is perfectly unambiguous to the compiler, of course, but it's
> misleading to the human.
>
> --
> Brent Royal-Gordon
> Architechies
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Brent Royal-Gordon via swift-evolution]

> On May 5, 2017, at 11:06 PM, Xiaodi Wu  wrote:
> 
> The identifier after a colon is *never* a type in any pattern matching, and 
> there's no need of which I'm aware to support type annotations in pattern 
> matching. We put colons after labels, and the current syntax is perfectly 
> consistent here. What is the defect you're trying to cure?

The defect underlying this proposal: `let (x: Int, y: Double)` looks like it's 
declaring `x` and `y` of types `Int` and `Double`, but it's actually declaring 
`Int` and `Double` and binding them to `x` and `y`. Your code's meaning is 
perfectly unambiguous to the compiler, of course, but it's misleading to the 
human.

-- 
Brent Royal-Gordon
Architechies

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

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

[Xiaodi Wu via swift-evolution]

This is exactly the syntax for enum case patterns in switch statements.
You're asserting that it's inconsistent with something, but I don't see any
inconsistency. I don't understand what you mean by right-to-left assignment
or inout variables.

Robert's example is confusing because the variables are interestingly
named, but it is not a real-world error that can be made because you do not
have variables named x and y, and the compiler would shout errors at you in
short order if you tried to use them.
On Sat, May 6, 2017 at 10:12 Adrian Zubarev 
wrote:

> There is nothing consistent in the following example:
>
> let (x: a, y: b) = (x: 0, y: 1)
>
> Labels are not simple descriptors, they signal that the assignment for the
> RHS will happen to some constant associated with the label. The assignment
> direction is from right-to-left! Labeled tuple destructuring breaks this
> rule. Furthermore you’re not allowed to think of a and b as if they were
> some inout variables for the purpose of the assignment there.
>
> The syntax is ambiguous to the rest of the language and also exactly the
> case why the following code is not only confusing but simply mentally wrong:
>
> let (x: Int, y: Double) = (3, 1)
> let result = Int + Double // 4
>
>
>
> --
> Adrian Zubarev
> Sent with Airmail
>
> Am 6. Mai 2017 um 08:06:30, Xiaodi Wu (xiaodi...@gmail.com) schrieb:
>
> The identifier after a colon is *never* a type in any pattern matching,
> and there's no need of which I'm aware to support type annotations in
> pattern matching. We put colons after labels, and the current syntax is
> perfectly consistent here. What is the defect you're trying to cure?
> On Fri, May 5, 2017 at 22:42 Brent Royal-Gordon 
> wrote:
>
>> Sorry for wrecking the threading, but any chance we could change the
>> syntax to:
>>
>> let (x myX: Int, y myY: Int) = ...
>>
>> That would ensure the identifier after the colon was always treated as a
>> type. I suppose if you wanted to infer the type, it'd be:
>>
>> let (x myX, y myY) = ...
>>
>> --
>> Brent Royal-Gordon
>> Sent from my iPhone
>>
>> On May 5, 2017, at 12:04 AM, Adrian Zubarev via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> If we ban reordering now, than I don’t see choosing different names in
>> tuple destructuring as a strong argument of allowing labels there let
>> (x: a, y: b). They’re literally the same as one would write comments
>> inside the destructured tuple let (/* my x */ x, /* my y*/ y).
>>
>>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Adrian Zubarev via swift-evolution]

There is nothing consistent in the following example:

let (x: a, y: b) = (x: 0, y: 1)
Labels are not simple descriptors, they signal that the assignment for the RHS 
will happen to some constant associated with the label. The assignment 
direction is from right-to-left! Labeled tuple destructuring breaks this rule. 
Furthermore you’re not allowed to think of a and b as if they were some inout 
variables for the purpose of the assignment there.

The syntax is ambiguous to the rest of the language and also exactly the case 
why the following code is not only confusing but simply mentally wrong:

let (x: Int, y: Double) = (3, 1)
let result = Int + Double // 4


-- 
Adrian Zubarev
Sent with Airmail

Am 6. Mai 2017 um 08:06:30, Xiaodi Wu (xiaodi...@gmail.com) schrieb:

The identifier after a colon is *never* a type in any pattern matching, and 
there's no need of which I'm aware to support type annotations in pattern 
matching. We put colons after labels, and the current syntax is perfectly 
consistent here. What is the defect you're trying to cure?
On Fri, May 5, 2017 at 22:42 Brent Royal-Gordon  wrote:
Sorry for wrecking the threading, but any chance we could change the syntax to:

let (x myX: Int, y myY: Int) = ...

That would ensure the identifier after the colon was always treated as a type. 
I suppose if you wanted to infer the type, it'd be:

let (x myX, y myY) = ...

-- 
Brent Royal-Gordon
Sent from my iPhone

On May 5, 2017, at 12:04 AM, Adrian Zubarev via swift-evolution 
 wrote:

If we ban reordering now, than I don’t see choosing different names in tuple 
destructuring as a strong argument of allowing labels there let (x: a, y: b). 
They’re literally the same as one would write comments inside the destructured 
tuple let (/* my x */ x, /* my y*/ y).
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Dany St-Amant via swift-evolution]

Still confused about what is removed and what is confusing, all example use 
identical label and variable name and construct which seems atypical. I think 
that a better shuffling example (at least I think it's shuffling) would be a 
date tuple. All expect such tuple to contains a day, a month and a year, but 
their expected order varies around the world.

let date = Today
(day: currentDay, month: currentMonth, year: currentYear) = date
(year: currentYear, month: currentMonth, day: currentDay) = date
(month: currentMonth, day: currentDay, year: currentYear) = date
(year: currentYear, _, _) = date
(maybeDay, maybeYear, maybeMonth) = date

All these are allowed, first four are guaranteed to behave, the last is a 
gamble.

var dateDMY = britishToday()
var dateMDY = americanToday()
dateMDY = dateDMY

This works also perfectly fine.
So what is the impact on this perfectly sane examples.

Dany

Le 5 mai 2017 à 02:35, Xiaodi Wu via swift-evolution 
 a écrit :

>> On Fri, May 5, 2017 at 1:31 AM, Xiaodi Wu  wrote:
>>> On Fri, May 5, 2017 at 1:21 AM, Robert Widmann  
>>> wrote:
>> 
>>> Those labels anchored the reordering algorithm.  They guaranteed that 
>>> structural typing thing I brought up where you had to consume all the 
>>> labels in the type signature before you could continue, but that was where 
>>> their semantic value ended.  Given an ordering invariant, what matters are 
>>> the names you give to the values in the pattern.  Not the names given in, 
>>> say, the return value of the function - which as part of the type are 
>>> supposed to be irrelevant anyways.
>> 
>> There's more to Swift's syntax than what's solely required for the compiler 
>> to parse it. There are also the bits we put in to help humans write correct 
>> code.
>> 
>> This is one reason why SE-0111 was revised to permit "cosmetic" labels for 
>> functions after their type system significance was removed. With respect to 
>> tuples, I fully understand that if you remove the ability to reorder indices 
>> of a tuple, labels in tuple patterns won't "do" anything--other than assert 
>> that the poor human who's writing them has the tuple elements in the right 
>> order. But that's important. That's valuable.
> 
> Put concretely:
> 
> ```
> let tuple = (x: 1, y: 2)
> 
> // I, silly human, mistakenly think the elements in the tuple are
> // `y` first, then `x`. I'm a confused human. Now I write:
> 
> let (y: y, x: x) = tuple
> // Currently, does the right thing, even though I'm confused.
> 
> let (y: y, x: x) = tuple
> // Without tuple reordering, this produces an error, which corrects my 
> confusion.
> 
> let (y, x) = tuple
> // Oops. I'm out of luck.
> ```
> 
>>> Enum cases are a different kettle of fish since the last round of proposals 
>>> (specifically SE-0155).  Associated value clauses are no longer tuples.
>>> 
>>> Thank you for digging up that blog about this too.  I hadn't seen that 
>>> before I went into this - it came up because of code review related to some 
>>> fallout from SE-110.
>>> 
>>> ~Robert Widmann
>>> 
>>> 2017/05/05 2:09、Xiaodi Wu  のメッセージ:
>>> 
> On Fri, May 5, 2017 at 1:01 AM, Robert Widmann  
> wrote:
> 
> 
> ~Robert Widmann
> 
> 2017/05/05 1:42、Xiaodi Wu  のメッセージ:
> 
>>> On Fri, May 5, 2017 at 00:17 Robert Widmann  
>>> wrote:
>> 
>>> On the contrary, this is precisely what it means to deprecate tuple 
>>> shuffles.  You can’t map common parlance onto this term; the proposal 
>>> and the Twitter thread weren’t merely about reordering arguments.
>> 
>> Let's be clear: _all_ of your examples of "shuffles" in the proposal 
>> involve reordering. You defined a tuple shuffle as such: "an 
>> undocumented feature of Swift in which one can re-order the indices of a 
>> tuple" If you intend to propose a broader change, it is grossly 
>> misleading to write it up in this way.
> 
> They are both modeled by shuffles.  And we are spinning off into semantic 
> weeds I'd rather not spin off into.  The core of your counterargument is 
> the pattern change being bad for business.  Let's discuss that. 
> 
>> 
 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: [swift-evolution] [Proposal][Discussion] Deprecate Tuple Shuffles

[Xiaodi Wu via swift-evolution]

The identifier after a colon is *never* a type in any pattern matching, and
there's no need of which I'm aware to support type annotations in pattern
matching. We put colons after labels, and the current syntax is perfectly
consistent here. What is the defect you're trying to cure?
On Fri, May 5, 2017 at 22:42 Brent Royal-Gordon 
wrote:

> Sorry for wrecking the threading, but any chance we could change the
> syntax to:
>
> let (x myX: Int, y myY: Int) = ...
>
> That would ensure the identifier after the colon was always treated as a
> type. I suppose if you wanted to infer the type, it'd be:
>
> let (x myX, y myY) = ...
>
> --
> Brent Royal-Gordon
> Sent from my iPhone
>
> On May 5, 2017, at 12:04 AM, Adrian Zubarev via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> If we ban reordering now, than I don’t see choosing different names in
> tuple destructuring as a strong argument of allowing labels there let (x:
> a, y: b). They’re literally the same as one would write comments inside
> the destructured tuple let (/* my x */ x, /* my y*/ y).
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Brent Royal-Gordon via swift-evolution]

Sorry for wrecking the threading, but any chance we could change the syntax to:

let (x myX: Int, y myY: Int) = ...

That would ensure the identifier after the colon was always treated as a type. 
I suppose if you wanted to infer the type, it'd be:

let (x myX, y myY) = ...

-- 
Brent Royal-Gordon
Sent from my iPhone

> On May 5, 2017, at 12:04 AM, Adrian Zubarev via swift-evolution 
>  wrote:
> 
> If we ban reordering now, than I don’t see choosing different names in tuple 
> destructuring as a strong argument of allowing labels there let (x: a, y: b). 
> They’re literally the same as one would write comments inside the 
> destructured tuple let (/* my x */ x, /* my y*/ y).
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Robert Widmann via swift-evolution]

~Robert Widmann

2017/05/05 14:07、John McCall  のメッセージ:

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

Exactly. I've since removed this example.  My initial confusion was around the 
labeled matching being a thing at all. 

>> - 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.  
>> 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.
> 
>> 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 
  wrote:
 
 
 On 5 May 2017, at 12:27, Félix Cloutier via swift-evolution 
  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
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[John McCall via swift-evolution]

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

> 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 
>> > wrote:
>> 
>> 
>>> On 5 May 2017, at 12:27, Félix Cloutier via swift-evolution 
>>> > 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

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

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

[Anders Ha via swift-evolution]

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 
>  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 
>> > 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-
>>>
>>> 
>>>  * 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 )
>>> 

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

[Jose Cheyo Jimenez via swift-evolution]

I filled a bug report. https://bugs.swift.org/browse/SR-4811 



> On May 5, 2017, at 9:38 AM, Jose Cheyo Jimenez  wrote:
> 
> 
>> On May 5, 2017, at 8:34 AM, Vladimir.S > > 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 
>>>  
>>> >> 
>>> 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-

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

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

[Jose Cheyo Jimenez via swift-evolution]

> On May 5, 2017, at 8:34 AM, Vladimir.S  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 
>> > 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-
>>>
>>> 
>>>  * 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 
>>> 

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

[Vladimir.S via swift-evolution]

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


  * 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 )
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

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

[T.J. Usiyan via swift-evolution]

```
let x: (r: Int, g: Int, b: Int, a: Int) = (255, 255, 255, 0)
let y: (a: Int, r: Int, g: Int, b: Int) = x

print(y.a) // currently, prints "0"
```

^^I would like for this not to be possible.

That is not at all what I expect or–even now that I see what is
happening–desire in any way.

TJ

On Fri, May 5, 2017 at 8:28 AM, Adrian Zubarev via swift-evolution <
swift-evolution@swift.org> wrote:

> To solve the issues with the destructuring I’d suggest to make the labels
> fully optional, so extracting inner tuples wouldn’t be a pain in the ass as
> it is right now.
>
> let tuple = (value: 0, point: (x: 0, y: 0, z: 0))
>
> let (value, point: (x, y, z)) = tuple
>
> Alternatively one could remove labels completely and let the compiler
> provide a suggestion for name of each value of the tuple destructuring, or
> you could your own names, while inner path would have some function-like
> syntax instead of confusing labels.
>
> let (value, point(x, y, z)) = tuple
>
> The latter would mean that tuple destructuring would always remove the
> labels from rhs tuple.
>
> In the example from above we’d get a change from:
>
> (value: Int, point: (x: Int, y: Int, z:Int)) to (Int, (Int, Int, Int)).
>
>
>
> --
> Adrian Zubarev
> Sent with Airmail
>
> Am 5. Mai 2017 um 14:07:11, André Videla (andre.vid...@gmail.com) schrieb:
>
> It really strikes me as an inconsistency in the type system. The type
> system already enforces order in other labeled expression like function
> calls
>
> func takePair(x: Int, y: Int) { }
>
> takePair(y: 5, x: 5) // error
>
> func takePair(y: Int, x: Int) { }
>
> takePair(y: 5, x: 5) // ok, dispatches to the second function because
> it's the only one that type checks with labels
>
> or enums
>
> enum Pair {
>
> case point(x: Int, y: Int)
>
> }
>
> let p: Pair = .point(y: 3, x: 4) // error
>
> Even if those features are semantically different and have nothing to do
> with the deconstruction of tuples they still suggest that labeling order is
> important. And teaches the programmer to expect that the order of labels is
> enforced.
>
> If you assume that label order is important why would you expect this to
> typecheck?
>
> let (y: a, x: b) = (x: 1, y: 2)
>
> let pair: (y: Int, x: Int) = (x: 1, y: 2)
>
> 2017-05-05 13:29 GMT+02:00 Adrian Zubarev via swift-evolution <
> swift-evolution@swift.org>:
>
>> I’m confused here. You’re referring to this example:
>>
>> let pair = (x: 3, y: 5)
>> let swapped: (y: Int, x: Int) = pair
>>
>> In this case you’re shuffling/swapping the labels of the type from:
>>
>> (x: Int, y: Int) to (y: Int, x: Int), which from my understanding of the
>> whole pitch should be an error. The tuple types may look similar, but
>> because the labels have a totally different order, I’d assume the types are
>> different even if they share the same labels and types.
>>
>>
>> --
>> Adrian Zubarev
>> Sent with Airmail
>>
>> Am 5. Mai 2017 um 13:12:31, David Hart (da...@hartbit.com) schrieb:
>>
>> But we’re not reordering labels, we’re assigning to a different variable
>> which has different variable names. And I think it should work because we
>> are not using the restructuring syntax.
>>
>> On 5 May 2017, at 12:11, Adrian Zubarev 
>> wrote:
>>
>> I would assume the error is correct, because if we ban reordering than
>> labeled tuple types will become incompatible if the labels are swapped,
>> remember the strict order or labels.
>>
>>
>>
>> --
>> Adrian Zubarev
>> Sent with Airmail
>>
>> Am 5. Mai 2017 um 12:08:59, David Hart via swift-evolution (
>> swift-evolution@swift.org) schrieb:
>>
>>
>>
>> On 5 May 2017, at 10:59, Xiaodi Wu via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> On Fri, May 5, 2017 at 03:11 André Videla  wrote:
>>
>>>
>>> Just to make sure:
>>>
>>> let pair = (x: 3, y: 5)
>>> Let swapped: (y: Int, x: Int) = pair
>>>
>>
>> Error.
>>
>>
>> Why error here? In this case. It's not a label but he type.
>>
>> Let (y: x1, x: y1) = pair
>>>
>>
>> Error.
>>
>> Let (x: x2, y: y2) = pair
>>>
>>
>> With the revised pitch that no longer prohibits all labels, x2 is 3 and
>> y2 is 5. In the original version, error.
>>
>> Let (x3, y3) = pair
>>>
>>
>> x3 is 3 and y3 is 5.
>>
>> After the change, What do (x_n, y_n) print and Which assignments are
>>> errors?
>>>
>>> Andre Videla
>>>
>>> On 5 May 2017, at 09:31, Xiaodi Wu via swift-evolution <
>>> swift-evolution@swift.org> wrote:
>>>
>>> On Fri, May 5, 2017 at 2:28 AM, Adrian Zubarev >> artist.com> wrote:
>>>
 I’m not arguing to remove all labels in Swift. Labels are great, this
 is a fact for sure. The point I was trying to make is that labels in tuples
 how either a meaning or not at all.

 // This is a shortcut for the tuple type `(x: Int, y: Int)`
 let foo = (x: 0, y: 0)

 // In this case the labels are only used for description,
 // they do not server any benefit here are most likely redundant
 

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

[Adrian Zubarev via swift-evolution]

To solve the issues with the destructuring I’d suggest to make the labels fully 
optional, so extracting inner tuples wouldn’t be a pain in the ass as it is 
right now.

let tuple = (value: 0, point: (x: 0, y: 0, z: 0))

let (value, point: (x, y, z)) = tuple
Alternatively one could remove labels completely and let the compiler provide a 
suggestion for name of each value of the tuple destructuring, or you could your 
own names, while inner path would have some function-like syntax instead of 
confusing labels.

let (value, point(x, y, z)) = tuple
The latter would mean that tuple destructuring would always remove the labels 
from rhs tuple.

In the example from above we’d get a change from:

(value: Int, point: (x: Int, y: Int, z:Int)) to (Int, (Int, Int, Int)).



-- 
Adrian Zubarev
Sent with Airmail

Am 5. Mai 2017 um 14:07:11, André Videla (andre.vid...@gmail.com) schrieb:

It really strikes me as an inconsistency in the type system. The type system 
already enforces order in other labeled expression like function calls
func takePair(x: Int, y: Int) { }

takePair(y: 5, x: 5) // error

func takePair(y: Int, x: Int) { }

takePair(y: 5, x: 5) // ok, dispatches to the second function because it's the 
only one that type checks with labels

or enums

enum Pair {

    case point(x: Int, y: Int)

}

let p: Pair = .point(y: 3, x: 4) // error

Even if those features are semantically different and have nothing to do with 
the deconstruction of tuples they still suggest that labeling order is 
important. And teaches the programmer to expect that the order of labels is 
enforced.

If you assume that label order is important why would you expect this to 
typecheck?

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

let pair: (y: Int, x: Int) = (x: 1, y: 2)


2017-05-05 13:29 GMT+02:00 Adrian Zubarev via swift-evolution 
:
I’m confused here. You’re referring to this example:

let pair = (x: 3, y: 5)
let swapped: (y: Int, x: Int) = pair
In this case you’re shuffling/swapping the labels of the type from:

(x: Int, y: Int) to (y: Int, x: Int), which from my understanding of the whole 
pitch should be an error. The tuple types may look similar, but because the 
labels have a totally different order, I’d assume the types are different even 
if they share the same labels and types.



-- 
Adrian Zubarev
Sent with Airmail

Am 5. Mai 2017 um 13:12:31, David Hart (da...@hartbit.com) schrieb:

But we’re not reordering labels, we’re assigning to a different variable which 
has different variable names. And I think it should work because we are not 
using the restructuring syntax.

On 5 May 2017, at 12:11, Adrian Zubarev  wrote:

I would assume the error is correct, because if we ban reordering than labeled 
tuple types will become incompatible if the labels are swapped, remember the 
strict order or labels. 




-- 
Adrian Zubarev
Sent with Airmail

Am 5. Mai 2017 um 12:08:59, David Hart via swift-evolution 
(swift-evolution@swift.org) schrieb:



On 5 May 2017, at 10:59, Xiaodi Wu via swift-evolution 
 wrote:

On Fri, May 5, 2017 at 03:11 André Videla  wrote:

Just to make sure:

let pair = (x: 3, y: 5)
Let swapped: (y: Int, x: Int) = pair

Error.

Why error here? In this case. It's not a label but he type.

Let (y: x1, x: y1) = pair

Error.

Let (x: x2, y: y2) = pair

With the revised pitch that no longer prohibits all labels, x2 is 3 and y2 is 
5. In the original version, error.

Let (x3, y3) = pair

x3 is 3 and y3 is 5.

After the change, What do (x_n, y_n) print and Which assignments are errors?

Andre Videla 

On 5 May 2017, at 09:31, Xiaodi Wu via swift-evolution 
 wrote:

On Fri, May 5, 2017 at 2:28 AM, Adrian Zubarev 
 wrote:
I’m not arguing to remove all labels in Swift. Labels are great, this is a fact 
for sure. The point I was trying to make is that labels in tuples how either a 
meaning or not at all.

// This is a shortcut for the tuple type `(x: Int, y: Int)`
let foo = (x: 0, y: 0) 

// In this case the labels are only used for description, 
// they do not server any benefit here are most likely redundant
let (x: x, y: y) = foo 
Labels elsewhere are a different story and I do support the cosmetic addition 
Chris Lattner sketched out here: 
https://lists.swift.org/pipermail/swift-evolution-announce/2016-July/000233.html

However this is about closures and not tuples, I don’t think this would anyhow 
affect the removal of labels in tuple destructuring.

Plus I don’t see this to create an inconsistent in Swift, because as I already 
said, labels in tuple destructuring are useless.

How come? I just illustrated their use. They help humans write correct code by 
allowing the compiler to check an assertion that the human knows which labels 
go with which positions in the tuple.
___

swift-evolution mailing list

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

[Adrian Zubarev via swift-evolution]

I don’t understand your question. Those two lines of code should be an error 
and it’s exactly what the current draft is trying to fix.

This behavior is truly inconsistent.



-- 
Adrian Zubarev
Sent with Airmail

Am 5. Mai 2017 um 14:07:11, André Videla (andre.vid...@gmail.com) schrieb:

If you assume that label order is important why would you expect this to 
typecheck?

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

let pair: (y: Int, x: Int) = (x: 1, y: 2)

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

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

[Adrian Zubarev via swift-evolution]

I’m confused here. You’re referring to this example:

let pair = (x: 3, y: 5)
let swapped: (y: Int, x: Int) = pair
In this case you’re shuffling/swapping the labels of the type from:

(x: Int, y: Int) to (y: Int, x: Int), which from my understanding of the whole 
pitch should be an error. The tuple types may look similar, but because the 
labels have a totally different order, I’d assume the types are different even 
if they share the same labels and types.



-- 
Adrian Zubarev
Sent with Airmail

Am 5. Mai 2017 um 13:12:31, David Hart (da...@hartbit.com) schrieb:

But we’re not reordering labels, we’re assigning to a different variable which 
has different variable names. And I think it should work because we are not 
using the restructuring syntax.

On 5 May 2017, at 12:11, Adrian Zubarev  wrote:

I would assume the error is correct, because if we ban reordering than labeled 
tuple types will become incompatible if the labels are swapped, remember the 
strict order or labels. 




-- 
Adrian Zubarev
Sent with Airmail

Am 5. Mai 2017 um 12:08:59, David Hart via swift-evolution 
(swift-evolution@swift.org) schrieb:



On 5 May 2017, at 10:59, Xiaodi Wu via swift-evolution 
 wrote:

On Fri, May 5, 2017 at 03:11 André Videla  wrote:

Just to make sure:

let pair = (x: 3, y: 5)
Let swapped: (y: Int, x: Int) = pair

Error.

Why error here? In this case. It's not a label but he type.

Let (y: x1, x: y1) = pair

Error.

Let (x: x2, y: y2) = pair

With the revised pitch that no longer prohibits all labels, x2 is 3 and y2 is 
5. In the original version, error.

Let (x3, y3) = pair

x3 is 3 and y3 is 5.

After the change, What do (x_n, y_n) print and Which assignments are errors?

Andre Videla 

On 5 May 2017, at 09:31, Xiaodi Wu via swift-evolution 
 wrote:

On Fri, May 5, 2017 at 2:28 AM, Adrian Zubarev 
 wrote:
I’m not arguing to remove all labels in Swift. Labels are great, this is a fact 
for sure. The point I was trying to make is that labels in tuples how either a 
meaning or not at all.

// This is a shortcut for the tuple type `(x: Int, y: Int)`
let foo = (x: 0, y: 0)

// In this case the labels are only used for description,
// they do not server any benefit here are most likely redundant
let (x: x, y: y) = foo
Labels elsewhere are a different story and I do support the cosmetic addition 
Chris Lattner sketched out here: 
https://lists.swift.org/pipermail/swift-evolution-announce/2016-July/000233.html

However this is about closures and not tuples, I don’t think this would anyhow 
affect the removal of labels in tuple destructuring.

Plus I don’t see this to create an inconsistent in Swift, because as I already 
said, labels in tuple destructuring are useless.

How come? I just illustrated their use. They help humans write correct code by 
allowing the compiler to check an assertion that the human knows which labels 
go with which positions in the tuple.
___

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

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

[David Hart via swift-evolution]

But we’re not reordering labels, we’re assigning to a different variable which 
has different variable names. And I think it should work because we are not 
using the restructuring syntax.

> On 5 May 2017, at 12:11, Adrian Zubarev  
> wrote:
> 
> I would assume the error is correct, because if we ban reordering than 
> labeled tuple types will become incompatible if the labels are swapped, 
> remember the strict order or labels. 
> 
> 
> 
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> 
> Am 5. Mai 2017 um 12:08:59, David Hart via swift-evolution 
> (swift-evolution@swift.org ) schrieb:
> 
>> 
>> 
>> On 5 May 2017, at 10:59, Xiaodi Wu via swift-evolution 
>> > wrote:
>> 
>>> On Fri, May 5, 2017 at 03:11 André Videla >> > wrote:
>>> 
>>> Just to make sure:
>>> 
>>> let pair = (x: 3, y: 5)
>>> Let swapped: (y: Int, x: Int) = pair
>>> 
>>> Error.
>> 
>> Why error here? In this case. It's not a label but he type.
>> 
>>> Let (y: x1, x: y1) = pair
>>> 
>>> Error.
>>> 
>>> Let (x: x2, y: y2) = pair
>>> 
>>> With the revised pitch that no longer prohibits all labels, x2 is 3 and y2 
>>> is 5. In the original version, error.
>>> 
>>> Let (x3, y3) = pair
>>> 
>>> x3 is 3 and y3 is 5.
>>> 
>>> After the change, What do (x_n, y_n) print and Which assignments are errors?
>>> 
>>> Andre Videla 
>>> 
>>> On 5 May 2017, at 09:31, Xiaodi Wu via swift-evolution 
>>> > wrote:
>>> 
 On Fri, May 5, 2017 at 2:28 AM, Adrian Zubarev 
 > 
 wrote:
 I’m not arguing to remove all labels in Swift. Labels are great, this is a 
 fact for sure. The point I was trying to make is that labels in tuples how 
 either a meaning or not at all.
 
 // This is a shortcut for the tuple type `(x: Int, y: Int)`
 let foo = (x: 0, y: 0)   
 
 // In this case the labels are only used for description,   
 // they do not server any benefit here are most likely redundant
 let (x: x, y: y) = foo   
 Labels elsewhere are a different story and I do support the cosmetic 
 addition Chris Lattner sketched out here: 
 https://lists.swift.org/pipermail/swift-evolution-announce/2016-July/000233.html
  
 
 However this is about closures and not tuples, I don’t think this would 
 anyhow affect the removal of labels in tuple destructuring.
 
 Plus I don’t see this to create an inconsistent in Swift, because as I 
 already said, labels in tuple destructuring are useless.
 
 How come? I just illustrated their use. They help humans write correct 
 code by allowing the compiler to check an assertion that the human knows 
 which labels go with which positions in the tuple.
>>> 
 ___
>>> 
 
 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 
>>> 
>> ___
>> 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

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

[Adrian Zubarev via swift-evolution]

IMHO the following line of code contains a highly inconsistent syntax, because 
the rhs uses labels for some sort of assignment, where the lhs just marks a 
constant/variable after the colon.

let (x: x, y: y) = (x: 0, y: 0) // valid today


-- 
Adrian Zubarev
Sent with Airmail

Am 5. Mai 2017 um 12:42:11, Adrian Zubarev (adrian.zuba...@devandartist.com) 
schrieb:

Labels create more harm in tuple destructuring than they solve.

let point = (x: 0, y: 0)

let (myX, myY) = point // fine
let (x: my_X, y: my_Y) = point // fine

let tuple = (a: 0, innerTuple: point)

let (myA, myInnerTuple) = tuple

// The following destructuring can extract nested tuples as well
let (a: a, innerTuple: (x: x, y: y)) = tuple // fine

// Let's try the same without labels
let (my_A, (myNewX, myNewY)) = tuple
// error: cannot express tuple conversion '(a: Int, innerTuple: (x: Int, y: 
Int))' to '(Int, (Int, Int))'
// Wait what? It did worked above with `point`

// Let's try something else
let (a: _, innerTuple: (newX, newY)) = tuple
// '(a: Int, innerTuple: (x: Int, y: Int))' to '(a: Int, innerTuple: (Int, 
Int))'

// Yet another approach
let (a: _, innerTuple: inner) = tuple // fine
>From this I conclude that tuple destructuring creates a new tuple, which is 
>not my intention at all, at least not in terms of extracting data. The types 
>become incompatible with each other if not labeled properly and that’s why we 
>cannot omit unwanted labels and are forced to either type them all out to 
>extract nested data or none of them at all.



-- 
Adrian Zubarev
Sent with Airmail

Am 5. Mai 2017 um 09:32:02, Xiaodi Wu (xiaodi...@gmail.com) schrieb:

On Fri, May 5, 2017 at 2:28 AM, Adrian Zubarev 
 wrote:
I’m not arguing to remove all labels in Swift. Labels are great, this is a fact 
for sure. The point I was trying to make is that labels in tuples how either a 
meaning or not at all.

// This is a shortcut for the tuple type `(x: Int, y: Int)`
let foo = (x: 0, y: 0)

// In this case the labels are only used for description,
// they do not server any benefit here are most likely redundant
let (x: x, y: y) = foo
Labels elsewhere are a different story and I do support the cosmetic addition 
Chris Lattner sketched out here: 
https://lists.swift.org/pipermail/swift-evolution-announce/2016-July/000233.html

However this is about closures and not tuples, I don’t think this would anyhow 
affect the removal of labels in tuple destructuring.

Plus I don’t see this to create an inconsistent in Swift, because as I already 
said, labels in tuple destructuring are useless.

How come? I just illustrated their use. They help humans write correct code by 
allowing the compiler to check an assertion that the human knows which labels 
go with which positions in the tuple.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Adrian Zubarev via swift-evolution]

Labels create more harm in tuple destructuring than they solve.

let point = (x: 0, y: 0)

let (myX, myY) = point // fine
let (x: my_X, y: my_Y) = point // fine

let tuple = (a: 0, innerTuple: point)

let (myA, myInnerTuple) = tuple

// The following destructuring can extract nested tuples as well
let (a: a, innerTuple: (x: x, y: y)) = tuple // fine

// Let's try the same without labels
let (my_A, (myNewX, myNewY)) = tuple
// error: cannot express tuple conversion '(a: Int, innerTuple: (x: Int, y: 
Int))' to '(Int, (Int, Int))'
// Wait what? It did worked above with `point`

// Let's try something else
let (a: _, innerTuple: (newX, newY)) = tuple
// '(a: Int, innerTuple: (x: Int, y: Int))' to '(a: Int, innerTuple: (Int, 
Int))'

// Yet another approach
let (a: _, innerTuple: inner) = tuple // fine
>From this I conclude that tuple destructuring creates a new tuple, which is 
>not my intention at all, at least not in terms of extracting data. The types 
>become incompatible with each other if not labeled properly and that’s why we 
>cannot omit unwanted labels and are forced to either type them all out to 
>extract nested data or none of them at all.



-- 
Adrian Zubarev
Sent with Airmail

Am 5. Mai 2017 um 09:32:02, Xiaodi Wu (xiaodi...@gmail.com) schrieb:

On Fri, May 5, 2017 at 2:28 AM, Adrian Zubarev 
 wrote:
I’m not arguing to remove all labels in Swift. Labels are great, this is a fact 
for sure. The point I was trying to make is that labels in tuples how either a 
meaning or not at all.

// This is a shortcut for the tuple type `(x: Int, y: Int)`
let foo = (x: 0, y: 0)   

// In this case the labels are only used for description,   
// they do not server any benefit here are most likely redundant
let (x: x, y: y) = foo   
Labels elsewhere are a different story and I do support the cosmetic addition 
Chris Lattner sketched out here: 
https://lists.swift.org/pipermail/swift-evolution-announce/2016-July/000233.html

However this is about closures and not tuples, I don’t think this would anyhow 
affect the removal of labels in tuple destructuring.

Plus I don’t see this to create an inconsistent in Swift, because as I already 
said, labels in tuple destructuring are useless.

How come? I just illustrated their use. They help humans write correct code by 
allowing the compiler to check an assertion that the human knows which labels 
go with which positions in the tuple.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Adrian Zubarev via swift-evolution]

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
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Adrian Zubarev via swift-evolution]

I would assume the error is correct, because if we ban reordering than labeled 
tuple types will become incompatible if the labels are swapped, remember the 
strict order or labels.



-- 
Adrian Zubarev
Sent with Airmail

Am 5. Mai 2017 um 12:08:59, David Hart via swift-evolution 
(swift-evolution@swift.org) schrieb:



On 5 May 2017, at 10:59, Xiaodi Wu via swift-evolution 
 wrote:

On Fri, May 5, 2017 at 03:11 André Videla  wrote:

Just to make sure:

let pair = (x: 3, y: 5)
Let swapped: (y: Int, x: Int) = pair

Error.

Why error here? In this case. It's not a label but he type.

Let (y: x1, x: y1) = pair

Error.

Let (x: x2, y: y2) = pair

With the revised pitch that no longer prohibits all labels, x2 is 3 and y2 is 
5. In the original version, error.

Let (x3, y3) = pair

x3 is 3 and y3 is 5.

After the change, What do (x_n, y_n) print and Which assignments are errors?

Andre Videla 

On 5 May 2017, at 09:31, Xiaodi Wu via swift-evolution 
 wrote:

On Fri, May 5, 2017 at 2:28 AM, Adrian Zubarev 
 wrote:
I’m not arguing to remove all labels in Swift. Labels are great, this is a fact 
for sure. The point I was trying to make is that labels in tuples how either a 
meaning or not at all.

// This is a shortcut for the tuple type `(x: Int, y: Int)`
let foo = (x: 0, y: 0)   

// In this case the labels are only used for description,   
// they do not server any benefit here are most likely redundant
let (x: x, y: y) = foo   
Labels elsewhere are a different story and I do support the cosmetic addition 
Chris Lattner sketched out here: 
https://lists.swift.org/pipermail/swift-evolution-announce/2016-July/000233.html

However this is about closures and not tuples, I don’t think this would anyhow 
affect the removal of labels in tuple destructuring.

Plus I don’t see this to create an inconsistent in Swift, because as I already 
said, labels in tuple destructuring are useless.

How come? I just illustrated their use. They help humans write correct code by 
allowing the compiler to check an assertion that the human knows which labels 
go with which positions in the tuple.
___

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

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

[David Hart via swift-evolution]

> On 5 May 2017, at 10:59, Xiaodi Wu via swift-evolution 
>  wrote:
> 
>> On Fri, May 5, 2017 at 03:11 André Videla  wrote:
>> 
>> Just to make sure:
>> 
>> let pair = (x: 3, y: 5)
>> Let swapped: (y: Int, x: Int) = pair
> 
> Error.

Why error here? In this case. It's not a label but he type.

>> Let (y: x1, x: y1) = pair
> 
> Error.
> 
>> Let (x: x2, y: y2) = pair
> 
> With the revised pitch that no longer prohibits all labels, x2 is 3 and y2 is 
> 5. In the original version, error.
> 
>> Let (x3, y3) = pair
> 
> x3 is 3 and y3 is 5.
> 
>> After the change, What do (x_n, y_n) print and Which assignments are errors?
>> 
>> Andre Videla 
>> 
>>> On 5 May 2017, at 09:31, Xiaodi Wu via swift-evolution 
>>>  wrote:
>>> 
 On Fri, May 5, 2017 at 2:28 AM, Adrian Zubarev 
  wrote:
 I’m not arguing to remove all labels in Swift. Labels are great, this is a 
 fact for sure. The point I was trying to make is that labels in tuples how 
 either a meaning or not at all.
 
 // This is a shortcut for the tuple type `(x: Int, y: Int)`
 let foo = (x: 0, y: 0)  
 
 // In this case the labels are only used for description,  
 // they do not server any benefit here are most likely redundant
 let (x: x, y: y) = foo  
 Labels elsewhere are a different story and I do support the cosmetic 
 addition Chris Lattner sketched out here: 
 https://lists.swift.org/pipermail/swift-evolution-announce/2016-July/000233.html
 
 However this is about closures and not tuples, I don’t think this would 
 anyhow affect the removal of labels in tuple destructuring.
 
 Plus I don’t see this to create an inconsistent in Swift, because as I 
 already said, labels in tuple destructuring are useless.
 
>>> How come? I just illustrated their use. They help humans write correct code 
>>> by allowing the compiler to check an assertion that the human knows which 
>>> labels go with which positions in the tuple.
>> 
>>> ___
>> 
>>> 
>>> 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
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[André Videla via swift-evolution]

Then +1 for the revised pitch. I strongly believe this is a strict improvement 
over the current situation.

 (y: Int, x: Int) = (x: 1, y:2) really looks like a type error

Andre Videla 

> On 5 May 2017, at 10:59, Xiaodi Wu  wrote:
> 
>> On Fri, May 5, 2017 at 03:11 André Videla  wrote:
>> 
>> Just to make sure:
>> 
>> let pair = (x: 3, y: 5)
>> Let swapped: (y: Int, x: Int) = pair
> 
> Error.
> 
>> Let (y: x1, x: y1) = pair
> 
> Error.
> 
>> Let (x: x2, y: y2) = pair
> 
> With the revised pitch that no longer prohibits all labels, x2 is 3 and y2 is 
> 5. In the original version, error.
> 
>> Let (x3, y3) = pair
> 
> x3 is 3 and y3 is 5.
> 
>> After the change, What do (x_n, y_n) print and Which assignments are errors?
>> 
>> Andre Videla 
>> 
>>> On 5 May 2017, at 09:31, Xiaodi Wu via swift-evolution 
>>>  wrote:
>>> 
 On Fri, May 5, 2017 at 2:28 AM, Adrian Zubarev 
  wrote:
 I’m not arguing to remove all labels in Swift. Labels are great, this is a 
 fact for sure. The point I was trying to make is that labels in tuples how 
 either a meaning or not at all.
 
 // This is a shortcut for the tuple type `(x: Int, y: Int)`
 let foo = (x: 0, y: 0)  
 
 // In this case the labels are only used for description,  
 // they do not server any benefit here are most likely redundant
 let (x: x, y: y) = foo  
 Labels elsewhere are a different story and I do support the cosmetic 
 addition Chris Lattner sketched out here: 
 https://lists.swift.org/pipermail/swift-evolution-announce/2016-July/000233.html
 
 However this is about closures and not tuples, I don’t think this would 
 anyhow affect the removal of labels in tuple destructuring.
 
 Plus I don’t see this to create an inconsistent in Swift, because as I 
 already said, labels in tuple destructuring are useless.
 
>>> How come? I just illustrated their use. They help humans write correct code 
>>> by allowing the compiler to check an assertion that the human knows which 
>>> labels go with which positions in the tuple.
>> 
>>> ___
>> 
>>> 
>>> 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

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

[Haravikk via swift-evolution]

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.

> On 5 May 2017, at 03:14, Robert Widmann via swift-evolution 
>  wrote:
> 
> 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.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Xiaodi Wu via swift-evolution]

On Fri, May 5, 2017 at 03:11 André Videla  wrote:

>
> Just to make sure:
>
> let pair = (x: 3, y: 5)
> Let swapped: (y: Int, x: Int) = pair
>

Error.

Let (y: x1, x: y1) = pair
>

Error.

Let (x: x2, y: y2) = pair
>

With the revised pitch that no longer prohibits all labels, x2 is 3 and y2
is 5. In the original version, error.

Let (x3, y3) = pair
>

x3 is 3 and y3 is 5.

After the change, What do (x_n, y_n) print and Which assignments are errors?
>
> Andre Videla
>
> On 5 May 2017, at 09:31, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> On Fri, May 5, 2017 at 2:28 AM, Adrian Zubarev <
> adrian.zuba...@devandartist.com> wrote:
>
>> I’m not arguing to remove all labels in Swift. Labels are great, this is
>> a fact for sure. The point I was trying to make is that labels in tuples
>> how either a meaning or not at all.
>>
>> // This is a shortcut for the tuple type `(x: Int, y: Int)`
>> let foo = (x: 0, y: 0)
>>
>> // In this case the labels are only used for description,
>> // they do not server any benefit here are most likely redundant
>> let (x: x, y: y) = foo
>>
>> Labels elsewhere are a different story and I do support the cosmetic
>> addition Chris Lattner sketched out here:
>> https://lists.swift.org/pipermail/swift-evolution-announce/2016-July/000233.html
>>
>> However this is about closures and not tuples, I don’t think this would
>> anyhow affect the removal of labels in tuple destructuring.
>>
>> Plus I don’t see this to create an inconsistent in Swift, because as I
>> already said, labels in tuple destructuring are useless.
>>
> How come? I just illustrated their use. They help humans write correct
> code by allowing the compiler to check an assertion that the human knows
> which labels go with which positions in the tuple.
>
> ___
>
>
> 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

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

[Rien via swift-evolution]

> On 05 May 2017, at 09:59, Xiaodi Wu  wrote:
> 
> On Fri, May 5, 2017 at 2:56 AM, Rien  wrote:
> 
> > On 05 May 2017, at 09:31, Xiaodi Wu via swift-evolution 
> >  wrote:
> >
> > On Fri, May 5, 2017 at 2:28 AM, Adrian Zubarev 
> >  wrote:
> > I’m not arguing to remove all labels in Swift. Labels are great, this is a 
> > fact for sure. The point I was trying to make is that labels in tuples how 
> > either a meaning or not at all.
> >
> > // This is a shortcut for the tuple type `(x: Int, y: Int)`
> > let foo = (x: 0, y: 0)
> >
> > // In this case the labels are only used for description,
> > // they do not server any benefit here are most likely redundant
> > let (x: x, y: y) = foo
> >
> > Labels elsewhere are a different story and I do support the cosmetic 
> > addition Chris Lattner sketched out here: 
> > https://lists.swift.org/pipermail/swift-evolution-announce/2016-July/000233.html
> >
> > However this is about closures and not tuples, I don’t think this would 
> > anyhow affect the removal of labels in tuple destructuring.
> >
> > Plus I don’t see this to create an inconsistent in Swift, because as I 
> > already said, labels in tuple destructuring are useless.
> >
> > How come? I just illustrated their use. They help humans write correct code 
> > by allowing the compiler to check an assertion that the human knows which 
> > labels go with which positions in the tuple.
> 
> True, but the ability to define your own labels (instead of the API developer 
> defining them for you) can make your code more readable. and hence 
> maintainable.
> 
> I'm not sure I understand what you're suggesting here. Can you clarify?

In trying to explain, I discovered an error in my thinking… so please disregard.

Rien.

(Btw: Thanks for asking!)
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[André Videla via swift-evolution]

Just to make sure:

let pair = (x: 3, y: 5)
Let swapped: (y: Int, x: Int) = pair
Let (y: x1, x: y1) = pair
Let (x: x2, y: y2) = pair
Let (x3, y3) = pair

After the change, What do (x_n, y_n) print and Which assignments are errors?

Andre Videla 

>> On 5 May 2017, at 09:31, Xiaodi Wu via swift-evolution 
>>  wrote:
>> 
>> On Fri, May 5, 2017 at 2:28 AM, Adrian Zubarev 
>>  wrote:
>> I’m not arguing to remove all labels in Swift. Labels are great, this is a 
>> fact for sure. The point I was trying to make is that labels in tuples how 
>> either a meaning or not at all.
>> 
>> // This is a shortcut for the tuple type `(x: Int, y: Int)`
>> let foo = (x: 0, y: 0)  
>> 
>> // In this case the labels are only used for description,  
>> // they do not server any benefit here are most likely redundant
>> let (x: x, y: y) = foo  
>> Labels elsewhere are a different story and I do support the cosmetic 
>> addition Chris Lattner sketched out here: 
>> https://lists.swift.org/pipermail/swift-evolution-announce/2016-July/000233.html
>> 
>> However this is about closures and not tuples, I don’t think this would 
>> anyhow affect the removal of labels in tuple destructuring.
>> 
>> Plus I don’t see this to create an inconsistent in Swift, because as I 
>> already said, labels in tuple destructuring are useless.
>> 
> How come? I just illustrated their use. They help humans write correct code 
> by allowing the compiler to check an assertion that the human knows which 
> labels go with which positions in the tuple.
> ___
> 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

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

[Xiaodi Wu via swift-evolution]

On Fri, May 5, 2017 at 2:56 AM, Rien  wrote:

>
> > On 05 May 2017, at 09:31, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> > On Fri, May 5, 2017 at 2:28 AM, Adrian Zubarev <
> adrian.zuba...@devandartist.com> wrote:
> > I’m not arguing to remove all labels in Swift. Labels are great, this is
> a fact for sure. The point I was trying to make is that labels in tuples
> how either a meaning or not at all.
> >
> > // This is a shortcut for the tuple type `(x: Int, y: Int)`
> > let foo = (x: 0, y: 0)
> >
> > // In this case the labels are only used for description,
> > // they do not server any benefit here are most likely redundant
> > let (x: x, y: y) = foo
> >
> > Labels elsewhere are a different story and I do support the cosmetic
> addition Chris Lattner sketched out here: https://lists.swift.org/
> pipermail/swift-evolution-announce/2016-July/000233.html
> >
> > However this is about closures and not tuples, I don’t think this would
> anyhow affect the removal of labels in tuple destructuring.
> >
> > Plus I don’t see this to create an inconsistent in Swift, because as I
> already said, labels in tuple destructuring are useless.
> >
> > How come? I just illustrated their use. They help humans write correct
> code by allowing the compiler to check an assertion that the human knows
> which labels go with which positions in the tuple.
>
> True, but the ability to define your own labels (instead of the API
> developer defining them for you) can make your code more readable. and
> hence maintainable.
>

I'm not sure I understand what you're suggesting here. Can you clarify?
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Rien via swift-evolution]

> On 05 May 2017, at 09:31, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> On Fri, May 5, 2017 at 2:28 AM, Adrian Zubarev 
>  wrote:
> I’m not arguing to remove all labels in Swift. Labels are great, this is a 
> fact for sure. The point I was trying to make is that labels in tuples how 
> either a meaning or not at all.
> 
> // This is a shortcut for the tuple type `(x: Int, y: Int)`
> let foo = (x: 0, y: 0)  
> 
> // In this case the labels are only used for description,  
> // they do not server any benefit here are most likely redundant
> let (x: x, y: y) = foo  
> 
> Labels elsewhere are a different story and I do support the cosmetic addition 
> Chris Lattner sketched out here: 
> https://lists.swift.org/pipermail/swift-evolution-announce/2016-July/000233.html
> 
> However this is about closures and not tuples, I don’t think this would 
> anyhow affect the removal of labels in tuple destructuring.
> 
> Plus I don’t see this to create an inconsistent in Swift, because as I 
> already said, labels in tuple destructuring are useless.
> 
> How come? I just illustrated their use. They help humans write correct code 
> by allowing the compiler to check an assertion that the human knows which 
> labels go with which positions in the tuple.

True, but the ability to define your own labels (instead of the API developer 
defining them for you) can make your code more readable. and hence maintainable.

Rien.

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

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

[Xiaodi Wu via swift-evolution]

On Fri, May 5, 2017 at 2:28 AM, Adrian Zubarev <
adrian.zuba...@devandartist.com> wrote:

> I’m not arguing to remove all labels in Swift. Labels are great, this is a
> fact for sure. The point I was trying to make is that labels in tuples how
> either a meaning or not at all.
>
> // This is a shortcut for the tuple type `(x: Int, y: Int)`
> let foo = (x: 0, y: 0)
>
> // In this case the labels are only used for description,
> // they do not server any benefit here are most likely redundant
> let (x: x, y: y) = foo
>
> Labels elsewhere are a different story and I do support the cosmetic
> addition Chris Lattner sketched out here: https://lists.swift.org/
> pipermail/swift-evolution-announce/2016-July/000233.html
>
> However this is about closures and not tuples, I don’t think this would
> anyhow affect the removal of labels in tuple destructuring.
>
> Plus I don’t see this to create an inconsistent in Swift, because as I
> already said, labels in tuple destructuring are useless.
>
How come? I just illustrated their use. They help humans write correct code
by allowing the compiler to check an assertion that the human knows which
labels go with which positions in the tuple.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Adrian Zubarev via swift-evolution]

Sorry I meant to say: “The point I was trying to make is that labels in tuples 
have either a meaning or not at all."

-- 
Adrian Zubarev
Sent with Airmail

Am 5. Mai 2017 um 09:28:45, Adrian Zubarev (adrian.zuba...@devandartist.com) 
schrieb:

The point I was trying to make is that labels in tuples how either a meaning or 
not at all.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Xiaodi Wu via swift-evolution]

On Fri, May 5, 2017 at 2:27 AM, David Hart  wrote:

>
> On 5 May 2017, at 09:24, Xiaodi Wu  wrote:
>
> On Fri, May 5, 2017 at 2:22 AM, David Hart  wrote:
>
>>
>> On 5 May 2017, at 07:56, Xiaodi Wu  wrote:
>>
>> On Fri, May 5, 2017 at 12:54 AM, David Hart  wrote:
>>
>>>
>>> On 5 May 2017, at 07:17, Robert Widmann via swift-evolution <
>>> swift-evolution@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/res
>> ources/posts/2015-07-19-tuples-swift-advanced-usage-best-practices.org
>>
>>
>> I do know and use tuple destructuring. But AFAIK, that’s not the syntax
>> Robert wants to ban: its the labels in that syntax. As he says:
>>
>> *Note that a tuple shuffle is distinct from a re-assignment through a
>> tuple pattern. For example, this series of statements will continue to
>> function as before:*
>> *(z, y, x) = (x, z, y)*
>>
>
> I'n not saying that you don't know about tuple destructuring. I'm saying
> that the particular feature Robert wants to ban is covered in the article I
> linked to, which at least Google thinks is one of the most relevant
> articles on tuple destructuring in Swift. So, it's not as rare as Robert
> makes it out to be; plenty of people have talked about it.
>
>
> The article is still called "Advanced Usage”. Its difficult to state how
> rarely or common a feature is used but my intuition tells me this is a very
> rare feature. If we’ve discussed it on this list, it has escaped me. And
> I’ve never seen it in the wild.
>

I'd agree that using this feature to reorder things is likely to be very
rare. However, you've actually never seen someone destructure a tuple using
labels? That's surprising to me. I feel _guilty_ every time I destructure a
tuple knowingly not writing labels! It feels...risky.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Adrian Zubarev via swift-evolution]

I’m not arguing to remove all labels in Swift. Labels are great, this is a fact 
for sure. The point I was trying to make is that labels in tuples how either a 
meaning or not at all.

// This is a shortcut for the tuple type `(x: Int, y: Int)`
let foo = (x: 0, y: 0)  

// In this case the labels are only used for description,  
// they do not server any benefit here are most likely redundant
let (x: x, y: y) = foo  
Labels elsewhere are a different story and I do support the cosmetic addition 
Chris Lattner sketched out here: 
https://lists.swift.org/pipermail/swift-evolution-announce/2016-July/000233.html

However this is about closures and not tuples, I don’t think this would anyhow 
affect the removal of labels in tuple destructuring.

Plus I don’t see this to create an inconsistent in Swift, because as I already 
said, labels in tuple destructuring are useless.



-- 
Adrian Zubarev
Sent with Airmail

Am 5. Mai 2017 um 09:20:49, Xiaodi Wu (xiaodi...@gmail.com) schrieb:

On Fri, May 5, 2017 at 2:04 AM, Adrian Zubarev 
 wrote:
Personally I don’t see the latter as an issue, at least not in that particular 
example of yours, because you can always look up the type of your labeled tuple.

That's an argument that can be made for nearly all labels in the language, is 
it not? Function argument labels could be entirely removed, by your argument, 
since parameter names are completely visible in the documentation and you can 
always just look it up. Consider the rationale behind revising SE-0111 
expressly to allow "cosmetic" labels. As I said, many languages don't have 
labels, but Swift does.

Is there any benefit gained from labels in tuple destructuring? let (x: x, y: 
y) is redundant to my eyes. If we ban reordering now, than I don’t see choosing 
different names in tuple destructuring as a strong argument of allowing labels 
there let (x: a, y: b). They’re literally the same as one would write comments 
inside the destructured tuple let (/* my x */ x, /* my y*/ y).

If you look in the C++ parts of the Swift compiler, that's the style for 
arguments in function calls where in Swift we use argument labels. Same idea. 
Your argument would remove most if not all labels from the language.



-- 
Adrian Zubarev
Sent with Airmail

Am 5. Mai 2017 um 08:36:20, Xiaodi Wu via swift-evolution 
(swift-evolution@swift.org) schrieb:

```
let tuple = (x: 1, y: 2)

// I, silly human, mistakenly think the elements in the tuple are
// `y` first, then `x`. I'm a confused human. Now I write:

let (y: y, x: x) = tuple
// Currently, does the right thing, even though I'm confused.

let (y: y, x: x) = tuple
// Without tuple reordering, this produces an error, which corrects my 
confusion.

let (y, x) = tuple
// Oops. I'm out of luck.
```

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

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

[David Hart via swift-evolution]

> On 5 May 2017, at 09:24, Xiaodi Wu  wrote:
> 
> On Fri, May 5, 2017 at 2:22 AM, David Hart  > wrote:
> 
>> On 5 May 2017, at 07:56, Xiaodi Wu > > wrote:
>> 
>> On Fri, May 5, 2017 at 12:54 AM, David Hart > > wrote:
>> 
>> On 5 May 2017, at 07:17, Robert Widmann via swift-evolution 
>> > wrote:
>> 
>>> On the contrary, this is precisely what it means to deprecate tuple 
>>> shuffles.  You can’t map common parlance onto this term; the proposal and 
>>> the Twitter thread weren’t merely about reordering arguments.
>>> 
 but it is entirely another ballgame to remove labels from tuple patterns 
 altogether.
>>> 
>>> It’s really not.  Let me demonstrate:
>>> 
 To be clear, are you proposing the prohibition of *adding or removing* 
 labels as well? A previous discussion on tuple shuffling on this list saw 
 consensus that assigning a value of type (label1: T, label2: U) to a 
 variable of type (T, U) and vice versa should absolutely be supported, 
 whether or not reordering is permitted.
>>> 
>>> I am not proposing any changes to switching parameter labels through 
>>> well-typed re-assignments.  This is absolutely still going to be allowed:
>>> 
>>> var z : (Int, Int) = (0, 0)
>>> var w : (x : Int, y : Int) = (5, 10)
>>> z = w
>>> w = z
>>> 
>>> This is modeled internally with a tuple shuffle, but not the kind of 
>>> shuffle I’m interested in banning.  It’s a far simpler kind of 
>>> 
 And how about *restating* existing labels without any adding or removing? 
 To be clear:
 
 ```
 let (partialValue: v, overflow: o) = 42.addingReportingOverflow(42)
 ```
 
 ...involves absolutely no changes in labels whatsoever. The return type is 
 (partialValue: Int, overflow: ArithmeticOverflow).
>>> 
>>> That, however, is a kind of shuffle I intend to deprecate here.  This kind 
>>> of pattern is subject to the “arcane syntax” part of the proposal.
>>> 
 
 Either one of these scenarios is commonly used, and it is astonishing to 
 me that they would be eliminated.
>>> 
>>> Do you have proof of that claim? I have never seen the relevant kinds of 
>>> tuple shuffle used before, and I doubt you have either before today.
>> 
>> For what it's worth, I thought I knew Swift inside out and I had never seen 
>> or used the syntax your are proposing to ban, so I'm all for it.
>> 
>> If you google "Swift tuple destructuring," it's demonstrated in the third 
>> link you can click on. The article is even titled "best practices":
>> 
>> https://github.com/terhechte/appventure-blog/blob/master/resources/posts/2015-07-19-tuples-swift-advanced-usage-best-practices.org
>>  
>> 
> 
> I do know and use tuple destructuring. But AFAIK, that’s not the syntax 
> Robert wants to ban: its the labels in that syntax. As he says:
> 
> Note that a tuple shuffle is distinct from a re-assignment through a tuple 
> pattern. For example, this series of statements will continue to function as 
> before:
> (z, y, x) = (x, z, y)
> 
> I'n not saying that you don't know about tuple destructuring. I'm saying that 
> the particular feature Robert wants to ban is covered in the article I linked 
> to, which at least Google thinks is one of the most relevant articles on 
> tuple destructuring in Swift. So, it's not as rare as Robert makes it out to 
> be; plenty of people have talked about it.

The article is still called "Advanced Usage”. Its difficult to state how rarely 
or common a feature is used but my intuition tells me this is a very rare 
feature. If we’ve discussed it on this list, it has escaped me. And I’ve never 
seen it in the wild.

>>> ~Robert Widmann
>>> 
 On May 5, 2017, at 12:53 AM, Xiaodi Wu > 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 > 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 

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

[Xiaodi Wu via swift-evolution]

On Fri, May 5, 2017 at 2:14 AM, Xiaodi Wu  wrote:

> On Fri, May 5, 2017 at 1:44 AM, Robert Widmann 
> wrote:
>
>> I can see where you’re coming from, absolutely.  I don’t intend to remove
>> necessary semantic content labels can provide if I don’t have to.
>>
>> For the sake of expediency - and because even with labels you can
>> destructure into a label-less pattern, I’ll concede this point and remove
>> the section about removing labeled patterns from the draft on Github.
>>
>
> Without that chunk, I would be fine with the proposal. It removes a clever
> part of the language, but perhaps too clever and now rather unexpected,
> with the direction in which it's evolving.
>

I should add, there's an added benefit here. If you allow labels but remove
shuffling, there's a good chance that *unintentional* shuffles get called
out during migration. Boom, bugs fixed, better code. Swift saves the day.


>
>> ~Robert Widmann
>>
>> On May 5, 2017, at 2:35 AM, Xiaodi Wu  wrote:
>>
>> On Fri, May 5, 2017 at 1:31 AM, Xiaodi Wu  wrote:
>>
>>> On Fri, May 5, 2017 at 1:21 AM, Robert Widmann >> > wrote:
>>>
 Those labels anchored the reordering algorithm.  They guaranteed that
 structural typing thing I brought up where you had to consume all the
 labels in the type signature before you could continue, but that was where
 their semantic value ended.  Given an ordering invariant, what matters are
 the names *you* give to the values in the pattern.  Not the names
 given in, say, the return value of the function - which as part of the type
 are supposed to be irrelevant anyways.

>>>
>>> There's more to Swift's syntax than what's solely required for the
>>> compiler to parse it. There are also the bits we put in to help humans
>>> write correct code.
>>>
>>> This is one reason why SE-0111 was revised to permit "cosmetic" labels
>>> for functions after their type system significance was removed. With
>>> respect to tuples, I fully understand that if you remove the ability to
>>> reorder indices of a tuple, labels in tuple patterns won't "do"
>>> anything--other than assert that the poor human who's writing them has the
>>> tuple elements in the right order. But that's important. That's valuable.
>>>
>>
>> Put concretely:
>>
>> ```
>> let tuple = (x: 1, y: 2)
>>
>> // I, silly human, mistakenly think the elements in the tuple are
>> // `y` first, then `x`. I'm a confused human. Now I write:
>>
>> let (y: y, x: x) = tuple
>> // Currently, does the right thing, even though I'm confused.
>>
>> let (y: y, x: x) = tuple
>> // Without tuple reordering, this produces an error, which corrects my
>> confusion.
>>
>> let (y, x) = tuple
>> // Oops. I'm out of luck.
>> ```
>>
>> Enum cases are a different kettle of fish since the last round of
 proposals (specifically SE-0155).  Associated value clauses are no longer
 tuples.

 Thank you for digging up that blog about this too.  I hadn't seen that
 before I went into this - it came up because of code review related to some
 fallout from SE-110.

 ~Robert Widmann

 2017/05/05 2:09、Xiaodi Wu  のメッセージ:

 On Fri, May 5, 2017 at 1:01 AM, Robert Widmann <
 devteam.cod...@gmail.com> wrote:

>
>
> ~Robert Widmann
>
> 2017/05/05 1:42、Xiaodi Wu  のメッセージ:
>
> On Fri, May 5, 2017 at 00:17 Robert Widmann 
> wrote:
>
>> On the contrary, this is precisely what it means to deprecate tuple
>> shuffles.  You can’t map common parlance onto this term; the proposal and
>> the Twitter thread weren’t merely about reordering arguments.
>>
>
> Let's be clear: _all_ of your examples of "shuffles" in the proposal
> involve reordering. You defined a tuple shuffle as such: "an undocumented
> feature of Swift in which one can re-order the indices of a tuple" If
> you intend to propose a broader change, it is grossly misleading to write
> it up in this way.
>
>
> They are both modeled by shuffles.  And we are spinning off into
> semantic weeds I'd rather not spin off into.  The core of your
> counterargument is the pattern change being bad for business.  Let's
> discuss that.
>
>
> 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 

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

[Xiaodi Wu via swift-evolution]

On Fri, May 5, 2017 at 2:22 AM, David Hart  wrote:

>
> On 5 May 2017, at 07:56, Xiaodi Wu  wrote:
>
> On Fri, May 5, 2017 at 12:54 AM, David Hart  wrote:
>
>>
>> On 5 May 2017, at 07:17, Robert Widmann via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> On the contrary, this is precisely what it means to deprecate tuple
>> shuffles.  You can’t map common parlance onto this term; the proposal and
>> the Twitter thread weren’t merely about reordering arguments.
>>
>> but it is entirely another ballgame to remove labels from tuple patterns
>> altogether.
>>
>>
>> It’s really not.  Let me demonstrate:
>>
>> To be clear, are you proposing the prohibition of *adding or removing*
>>> labels as well? A previous discussion on tuple shuffling on this list saw
>>> consensus that assigning a value of type (label1: T, label2: U) to a
>>> variable of type (T, U) and vice versa should absolutely be supported,
>>> whether or not reordering is permitted.
>>
>>
>> I am not proposing any changes to switching parameter labels through
>> well-typed re-assignments.  This is absolutely still going to be allowed:
>>
>> var z : (Int, Int) = (0, 0)
>> var w : (x : Int, y : Int) = (5, 10)
>> z = w
>> w = z
>>
>> This is modeled internally with a tuple shuffle, but not the kind of
>> shuffle I’m interested in banning.  It’s a far simpler kind of
>>
>> And how about *restating* existing labels without any adding or removing?
>>> To be clear:
>>>
>>> ```
>>> let (partialValue: v, overflow: o) = 42.addingReportingOverflow(42)
>>> ```
>>>
>>> ...involves absolutely no changes in labels whatsoever. The return type
>>> is (partialValue: Int, overflow: ArithmeticOverflow).
>>>
>>
>> That, however, is a kind of shuffle I intend to deprecate here.  This
>> kind of pattern is subject to the “arcane syntax” part of the proposal.
>>
>>
>>> Either one of these scenarios is commonly used, and it is astonishing to
>>> me that they would be eliminated.
>>
>>
>> Do you have proof of that claim? I have never seen the relevant kinds of
>> tuple shuffle used before, and I doubt you have either before today.
>>
>>
>> For what it's worth, I thought I knew Swift inside out and I had never
>> seen or used the syntax your are proposing to ban, so I'm all for it.
>>
>
> If you google "Swift tuple destructuring," it's demonstrated in the third
> link you can click on. The article is even titled "best practices":
>
> https://github.com/terhechte/appventure-blog/blob/master/
> resources/posts/2015-07-19-tuples-swift-advanced-usage-best-practices.org
>
>
> I do know and use tuple destructuring. But AFAIK, that’s not the syntax
> Robert wants to ban: its the labels in that syntax. As he says:
>
> *Note that a tuple shuffle is distinct from a re-assignment through a
> tuple pattern. For example, this series of statements will continue to
> function as before:*
> *(z, y, x) = (x, z, y)*
>

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

~Robert Widmann
>>
>> On May 5, 2017, at 12:53 AM, Xiaodi Wu  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  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 

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

[David Hart via swift-evolution]

> On 5 May 2017, at 07:56, Xiaodi Wu  wrote:
> 
> On Fri, May 5, 2017 at 12:54 AM, David Hart  > wrote:
> 
> On 5 May 2017, at 07:17, Robert Widmann via swift-evolution 
> > wrote:
> 
>> On the contrary, this is precisely what it means to deprecate tuple 
>> shuffles.  You can’t map common parlance onto this term; the proposal and 
>> the Twitter thread weren’t merely about reordering arguments.
>> 
>>> but it is entirely another ballgame to remove labels from tuple patterns 
>>> altogether.
>> 
>> It’s really not.  Let me demonstrate:
>> 
>>> To be clear, are you proposing the prohibition of *adding or removing* 
>>> labels as well? A previous discussion on tuple shuffling on this list saw 
>>> consensus that assigning a value of type (label1: T, label2: U) to a 
>>> variable of type (T, U) and vice versa should absolutely be supported, 
>>> whether or not reordering is permitted.
>> 
>> I am not proposing any changes to switching parameter labels through 
>> well-typed re-assignments.  This is absolutely still going to be allowed:
>> 
>> var z : (Int, Int) = (0, 0)
>> var w : (x : Int, y : Int) = (5, 10)
>> z = w
>> w = z
>> 
>> This is modeled internally with a tuple shuffle, but not the kind of shuffle 
>> I’m interested in banning.  It’s a far simpler kind of 
>> 
>>> And how about *restating* existing labels without any adding or removing? 
>>> To be clear:
>>> 
>>> ```
>>> let (partialValue: v, overflow: o) = 42.addingReportingOverflow(42)
>>> ```
>>> 
>>> ...involves absolutely no changes in labels whatsoever. The return type is 
>>> (partialValue: Int, overflow: ArithmeticOverflow).
>> 
>> That, however, is a kind of shuffle I intend to deprecate here.  This kind 
>> of pattern is subject to the “arcane syntax” part of the proposal.
>> 
>>> 
>>> Either one of these scenarios is commonly used, and it is astonishing to me 
>>> that they would be eliminated.
>> 
>> Do you have proof of that claim? I have never seen the relevant kinds of 
>> tuple shuffle used before, and I doubt you have either before today.
> 
> For what it's worth, I thought I knew Swift inside out and I had never seen 
> or used the syntax your are proposing to ban, so I'm all for it.
> 
> If you google "Swift tuple destructuring," it's demonstrated in the third 
> link you can click on. The article is even titled "best practices":
> 
> https://github.com/terhechte/appventure-blog/blob/master/resources/posts/2015-07-19-tuples-swift-advanced-usage-best-practices.org
>  
> 

I do know and use tuple destructuring. But AFAIK, that’s not the syntax Robert 
wants to ban: its the labels in that syntax. As he says:

Note that a tuple shuffle is distinct from a re-assignment through a tuple 
pattern. For example, this series of statements will continue to function as 
before:
(z, y, x) = (x, z, y)

>> ~Robert Widmann
>> 
>>> On May 5, 2017, at 12:53 AM, Xiaodi Wu >> > 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 >> > 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 >> > wrote:
>>> That doesn't involve a parameter reordering, but because it 

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

[Xiaodi Wu via swift-evolution]

On Fri, May 5, 2017 at 2:04 AM, Adrian Zubarev <
adrian.zuba...@devandartist.com> wrote:

> Personally I don’t see the latter as an issue, at least not in that
> particular example of yours, because you can always look up the type of
> your labeled tuple.
>
That's an argument that can be made for nearly all labels in the language,
is it not? Function argument labels could be entirely removed, by your
argument, since parameter names are completely visible in the documentation
and you can always just look it up. Consider the rationale behind revising
SE-0111 expressly to allow "cosmetic" labels. As I said, many languages
don't have labels, but Swift does.

--
>
> Is there any benefit gained from labels in tuple destructuring? let (x:
> x, y: y) is redundant to my eyes. If we ban reordering now, than I don’t
> see choosing different names in tuple destructuring as a strong argument of
> allowing labels there let (x: a, y: b). They’re literally the same as one
> would write comments inside the destructured tuple let (/* my x */ x, /*
> my y*/ y).
>
If you look in the C++ parts of the Swift compiler, that's the style for
arguments in function calls where in Swift we use argument labels. Same
idea. Your argument would remove most if not all labels from the language.


>
> --
> Adrian Zubarev
> Sent with Airmail
>
> Am 5. Mai 2017 um 08:36:20, Xiaodi Wu via swift-evolution (
> swift-evolution@swift.org) schrieb:
>
> ```
> let tuple = (x: 1, y: 2)
>
> // I, silly human, mistakenly think the elements in the tuple are
> // `y` first, then `x`. I'm a confused human. Now I write:
>
> let (y: y, x: x) = tuple
> // Currently, does the right thing, even though I'm confused.
>
> let (y: y, x: x) = tuple
> // Without tuple reordering, this produces an error, which corrects my
> confusion.
>
> let (y, x) = tuple
> // Oops. I'm out of luck.
> ```
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Xiaodi Wu via swift-evolution]

On Fri, May 5, 2017 at 1:44 AM, Robert Widmann 
wrote:

> I can see where you’re coming from, absolutely.  I don’t intend to remove
> necessary semantic content labels can provide if I don’t have to.
>
> For the sake of expediency - and because even with labels you can
> destructure into a label-less pattern, I’ll concede this point and remove
> the section about removing labeled patterns from the draft on Github.
>

Without that chunk, I would be fine with the proposal. It removes a clever
part of the language, but perhaps too clever and now rather unexpected,
with the direction in which it's evolving.


> ~Robert Widmann
>
> On May 5, 2017, at 2:35 AM, Xiaodi Wu  wrote:
>
> On Fri, May 5, 2017 at 1:31 AM, Xiaodi Wu  wrote:
>
>> On Fri, May 5, 2017 at 1:21 AM, Robert Widmann 
>> wrote:
>>
>>> Those labels anchored the reordering algorithm.  They guaranteed that
>>> structural typing thing I brought up where you had to consume all the
>>> labels in the type signature before you could continue, but that was where
>>> their semantic value ended.  Given an ordering invariant, what matters are
>>> the names *you* give to the values in the pattern.  Not the names given
>>> in, say, the return value of the function - which as part of the type are
>>> supposed to be irrelevant anyways.
>>>
>>
>> There's more to Swift's syntax than what's solely required for the
>> compiler to parse it. There are also the bits we put in to help humans
>> write correct code.
>>
>> This is one reason why SE-0111 was revised to permit "cosmetic" labels
>> for functions after their type system significance was removed. With
>> respect to tuples, I fully understand that if you remove the ability to
>> reorder indices of a tuple, labels in tuple patterns won't "do"
>> anything--other than assert that the poor human who's writing them has the
>> tuple elements in the right order. But that's important. That's valuable.
>>
>
> Put concretely:
>
> ```
> let tuple = (x: 1, y: 2)
>
> // I, silly human, mistakenly think the elements in the tuple are
> // `y` first, then `x`. I'm a confused human. Now I write:
>
> let (y: y, x: x) = tuple
> // Currently, does the right thing, even though I'm confused.
>
> let (y: y, x: x) = tuple
> // Without tuple reordering, this produces an error, which corrects my
> confusion.
>
> let (y, x) = tuple
> // Oops. I'm out of luck.
> ```
>
> Enum cases are a different kettle of fish since the last round of
>>> proposals (specifically SE-0155).  Associated value clauses are no longer
>>> tuples.
>>>
>>> Thank you for digging up that blog about this too.  I hadn't seen that
>>> before I went into this - it came up because of code review related to some
>>> fallout from SE-110.
>>>
>>> ~Robert Widmann
>>>
>>> 2017/05/05 2:09、Xiaodi Wu  のメッセージ:
>>>
>>> On Fri, May 5, 2017 at 1:01 AM, Robert Widmann >> > wrote:
>>>


 ~Robert Widmann

 2017/05/05 1:42、Xiaodi Wu  のメッセージ:

 On Fri, May 5, 2017 at 00:17 Robert Widmann 
 wrote:

> On the contrary, this is precisely what it means to deprecate tuple
> shuffles.  You can’t map common parlance onto this term; the proposal and
> the Twitter thread weren’t merely about reordering arguments.
>

 Let's be clear: _all_ of your examples of "shuffles" in the proposal
 involve reordering. You defined a tuple shuffle as such: "an undocumented
 feature of Swift in which one can re-order the indices of a tuple" If
 you intend to propose a broader change, it is grossly misleading to write
 it up in this way.


 They are both modeled by shuffles.  And we are spinning off into
 semantic weeds I'd rather not spin off into.  The core of your
 counterargument is the pattern change being bad for business.  Let's
 discuss that.


 but it is entirely another ballgame to remove labels from tuple
> patterns altogether.
>
>
> It’s really not.  Let me demonstrate:
>
> To be clear, are you proposing the prohibition of *adding or removing*
>> labels as well? A previous discussion on tuple shuffling on this list saw
>> consensus that assigning a value of type (label1: T, label2: U) to a
>> variable of type (T, U) and vice versa should absolutely be supported,
>> whether or not reordering is permitted.
>
>
> I am not proposing any changes to switching parameter labels through
> well-typed re-assignments.  This is absolutely still going to be allowed:
>
> var z : (Int, Int) = (0, 0)
> var w : (x : Int, y : Int) = (5, 10)
> z = w
> w = z
>
> This is modeled internally with a tuple shuffle, but not the kind of
> shuffle I’m interested in banning.  It’s a far simpler kind of
>

 What is your proposed 

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

[Adrian Zubarev via swift-evolution]

Personally I don’t see the latter as an issue, at least not in that particular 
example of yours, because you can always look up the type of your labeled tuple.

Is there any benefit gained from labels in tuple destructuring? let (x: x, y: 
y) is redundant to my eyes. If we ban reordering now, than I don’t see choosing 
different names in tuple destructuring as a strong argument of allowing labels 
there let (x: a, y: b). They’re literally the same as one would write comments 
inside the destructured tuple let (/* my x */ x, /* my y*/ y).



-- 
Adrian Zubarev
Sent with Airmail

Am 5. Mai 2017 um 08:36:20, Xiaodi Wu via swift-evolution 
(swift-evolution@swift.org) schrieb:

```
let tuple = (x: 1, y: 2)

// I, silly human, mistakenly think the elements in the tuple are
// `y` first, then `x`. I'm a confused human. Now I write:

let (y: y, x: x) = tuple
// Currently, does the right thing, even though I'm confused.

let (y: y, x: x) = tuple
// Without tuple reordering, this produces an error, which corrects my 
confusion.

let (y, x) = tuple
// Oops. I'm out of luck.
```
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Goffredo Marocchi via swift-evolution]

That is weird indeed, there is need of more argument labels, like argument 
labels back in stored closures and callbacks, not even less argument labels all 
around :/.

-1 as a corner case of the language throws the baby out with the bathwater.

Sent from my iPhone

> On 5 May 2017, at 05:53, Xiaodi Wu via swift-evolution 
>  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  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  
>>> 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  のメッセージ:
>>> 
 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 
>  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-
> 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 

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

[Robert Widmann via swift-evolution]

What others have noted, in addition to our Twitter thread, is that this 
proposal has revealed the need for diagnostics about shadowing.  There are 
currently two boundaries in Swift along which we allow shadowing in the same 
scope: Function arguments and patterns.  If we can close both of those 
loopholes I would be much less skittish about labels.

~Robert Widmann

> On May 5, 2017, at 2:35 AM, Xiaodi Wu  wrote:
> 
> On Fri, May 5, 2017 at 1:31 AM, Xiaodi Wu  > wrote:
> On Fri, May 5, 2017 at 1:21 AM, Robert Widmann  > wrote:
> Those labels anchored the reordering algorithm.  They guaranteed that 
> structural typing thing I brought up where you had to consume all the labels 
> in the type signature before you could continue, but that was where their 
> semantic value ended.  Given an ordering invariant, what matters are the 
> names you give to the values in the pattern.  Not the names given in, say, 
> the return value of the function - which as part of the type are supposed to 
> be irrelevant anyways.
> 
> There's more to Swift's syntax than what's solely required for the compiler 
> to parse it. There are also the bits we put in to help humans write correct 
> code.
> 
> This is one reason why SE-0111 was revised to permit "cosmetic" labels for 
> functions after their type system significance was removed. With respect to 
> tuples, I fully understand that if you remove the ability to reorder indices 
> of a tuple, labels in tuple patterns won't "do" anything--other than assert 
> that the poor human who's writing them has the tuple elements in the right 
> order. But that's important. That's valuable.
> 
> Put concretely:
> 
> ```
> let tuple = (x: 1, y: 2)
> 
> // I, silly human, mistakenly think the elements in the tuple are
> // `y` first, then `x`. I'm a confused human. Now I write:
> 
> let (y: y, x: x) = tuple
> // Currently, does the right thing, even though I'm confused.
> 
> let (y: y, x: x) = tuple
> // Without tuple reordering, this produces an error, which corrects my 
> confusion.
> 
> let (y, x) = tuple
> // Oops. I'm out of luck.
> ```
> 
> Enum cases are a different kettle of fish since the last round of proposals 
> (specifically SE-0155).  Associated value clauses are no longer tuples.
> 
> Thank you for digging up that blog about this too.  I hadn't seen that before 
> I went into this - it came up because of code review related to some fallout 
> from SE-110.
> 
> ~Robert Widmann
> 
> 2017/05/05 2:09、Xiaodi Wu > 
> のメッセージ:
> 
>> On Fri, May 5, 2017 at 1:01 AM, Robert Widmann > > wrote:
>> 
>> 
>> ~Robert Widmann
>> 
>> 2017/05/05 1:42、Xiaodi Wu > 
>> のメッセージ:
>> 
>>> On Fri, May 5, 2017 at 00:17 Robert Widmann >> > wrote:
>>> On the contrary, this is precisely what it means to deprecate tuple 
>>> shuffles.  You can’t map common parlance onto this term; the proposal and 
>>> the Twitter thread weren’t merely about reordering arguments.
>>> 
>>> Let's be clear: _all_ of your examples of "shuffles" in the proposal 
>>> involve reordering. You defined a tuple shuffle as such: "an undocumented 
>>> feature of Swift in which one can re-order the indices of a tuple" If 
>>> you intend to propose a broader change, it is grossly misleading to write 
>>> it up in this way.
>> 
>> They are both modeled by shuffles.  And we are spinning off into semantic 
>> weeds I'd rather not spin off into.  The core of your counterargument is the 
>> pattern change being bad for business.  Let's discuss that. 
>> 
>>> 
 but it is entirely another ballgame to remove labels from tuple patterns 
 altogether.
>>> 
>>> It’s really not.  Let me demonstrate:
>>> 
 To be clear, are you proposing the prohibition of *adding or removing* 
 labels as well? A previous discussion on tuple shuffling on this list saw 
 consensus that assigning a value of type (label1: T, label2: U) to a 
 variable of type (T, U) and vice versa should absolutely be supported, 
 whether or not reordering is permitted.
>>> 
>>> I am not proposing any changes to switching parameter labels through 
>>> well-typed re-assignments.  This is absolutely still going to be allowed:
>>> 
>>> var z : (Int, Int) = (0, 0)
>>> var w : (x : Int, y : Int) = (5, 10)
>>> z = w
>>> w = z
>>> 
>>> This is modeled internally with a tuple shuffle, but not the kind of 
>>> shuffle I’m interested in banning.  It’s a far simpler kind of 
>>> 
>>> What is your proposed behavior for the following code?
>>> 
>>> ```
>>> let x: (r: Int, g: Int, b: Int, a: Int) = (255, 255, 255, 0)
>>> let y: (a: Int, r: Int, g: Int, b: Int) = x
>>> 
>>> print(y.a) // currently, prints "0"
>>> ```
>>> 

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

[Robert Widmann via swift-evolution]

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

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

[Robert Widmann via swift-evolution]

I can see where you’re coming from, absolutely.  I don’t intend to remove 
necessary semantic content labels can provide if I don’t have to.  

For the sake of expediency - and because even with labels you can destructure 
into a label-less pattern, I’ll concede this point and remove the section about 
removing labeled patterns from the draft on Github.

~Robert Widmann

> On May 5, 2017, at 2:35 AM, Xiaodi Wu  wrote:
> 
> On Fri, May 5, 2017 at 1:31 AM, Xiaodi Wu  > wrote:
> On Fri, May 5, 2017 at 1:21 AM, Robert Widmann  > wrote:
> Those labels anchored the reordering algorithm.  They guaranteed that 
> structural typing thing I brought up where you had to consume all the labels 
> in the type signature before you could continue, but that was where their 
> semantic value ended.  Given an ordering invariant, what matters are the 
> names you give to the values in the pattern.  Not the names given in, say, 
> the return value of the function - which as part of the type are supposed to 
> be irrelevant anyways.
> 
> There's more to Swift's syntax than what's solely required for the compiler 
> to parse it. There are also the bits we put in to help humans write correct 
> code.
> 
> This is one reason why SE-0111 was revised to permit "cosmetic" labels for 
> functions after their type system significance was removed. With respect to 
> tuples, I fully understand that if you remove the ability to reorder indices 
> of a tuple, labels in tuple patterns won't "do" anything--other than assert 
> that the poor human who's writing them has the tuple elements in the right 
> order. But that's important. That's valuable.
> 
> Put concretely:
> 
> ```
> let tuple = (x: 1, y: 2)
> 
> // I, silly human, mistakenly think the elements in the tuple are
> // `y` first, then `x`. I'm a confused human. Now I write:
> 
> let (y: y, x: x) = tuple
> // Currently, does the right thing, even though I'm confused.
> 
> let (y: y, x: x) = tuple
> // Without tuple reordering, this produces an error, which corrects my 
> confusion.
> 
> let (y, x) = tuple
> // Oops. I'm out of luck.
> ```
> 
> Enum cases are a different kettle of fish since the last round of proposals 
> (specifically SE-0155).  Associated value clauses are no longer tuples.
> 
> Thank you for digging up that blog about this too.  I hadn't seen that before 
> I went into this - it came up because of code review related to some fallout 
> from SE-110.
> 
> ~Robert Widmann
> 
> 2017/05/05 2:09、Xiaodi Wu > 
> のメッセージ:
> 
>> On Fri, May 5, 2017 at 1:01 AM, Robert Widmann > > wrote:
>> 
>> 
>> ~Robert Widmann
>> 
>> 2017/05/05 1:42、Xiaodi Wu > 
>> のメッセージ:
>> 
>>> On Fri, May 5, 2017 at 00:17 Robert Widmann >> > wrote:
>>> On the contrary, this is precisely what it means to deprecate tuple 
>>> shuffles.  You can’t map common parlance onto this term; the proposal and 
>>> the Twitter thread weren’t merely about reordering arguments.
>>> 
>>> Let's be clear: _all_ of your examples of "shuffles" in the proposal 
>>> involve reordering. You defined a tuple shuffle as such: "an undocumented 
>>> feature of Swift in which one can re-order the indices of a tuple" If 
>>> you intend to propose a broader change, it is grossly misleading to write 
>>> it up in this way.
>> 
>> They are both modeled by shuffles.  And we are spinning off into semantic 
>> weeds I'd rather not spin off into.  The core of your counterargument is the 
>> pattern change being bad for business.  Let's discuss that. 
>> 
>>> 
 but it is entirely another ballgame to remove labels from tuple patterns 
 altogether.
>>> 
>>> It’s really not.  Let me demonstrate:
>>> 
 To be clear, are you proposing the prohibition of *adding or removing* 
 labels as well? A previous discussion on tuple shuffling on this list saw 
 consensus that assigning a value of type (label1: T, label2: U) to a 
 variable of type (T, U) and vice versa should absolutely be supported, 
 whether or not reordering is permitted.
>>> 
>>> I am not proposing any changes to switching parameter labels through 
>>> well-typed re-assignments.  This is absolutely still going to be allowed:
>>> 
>>> var z : (Int, Int) = (0, 0)
>>> var w : (x : Int, y : Int) = (5, 10)
>>> z = w
>>> w = z
>>> 
>>> This is modeled internally with a tuple shuffle, but not the kind of 
>>> shuffle I’m interested in banning.  It’s a far simpler kind of 
>>> 
>>> What is your proposed behavior for the following code?
>>> 
>>> ```
>>> let x: (r: Int, g: Int, b: Int, a: Int) = (255, 255, 255, 0)
>>> let y: (a: Int, r: Int, g: Int, b: Int) = x
>>> 
>>> print(y.a) // currently, prints "0"
>>> ```
>>> 

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

[Rien via swift-evolution]

I think your misunderstanding helped a lot of people understand what is at 
issue here :-)

It did for me!

+1


Regards,
Rien

Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Balancingrock
Project: http://swiftfire.nl - A server for websites build in Swift






> On 05 May 2017, at 08:33, Adrian Zubarev via swift-evolution 
>  wrote:
> 
> I’m aware what a label is, I just had a small misunderstanding about nested 
> destructuring. ;-)
> 
> Issue solved for me.
> 
> let (a, b /* inner tuple */) = tuple
> 
> let (_, (x, y)) = tuple
> 
> +1 I don’t mind this change at all.
> 
> 
> 
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> 
> Am 5. Mai 2017 um 08:14:10, Xiaodi Wu (xiaodi...@gmail.com) schrieb:
> 
>> On Fri, May 5, 2017 at 1:12 AM, Adrian Zubarev 
>>  wrote:
>> Oh pardon, on the first glance I didn’t realized the issue with that example.
>> 
>> Here is an updated example that would work:
>> 
>> let (first, second: (x, y)): (first: Int, second: (x: Int, y: Int)) = tuple
>> 
>> This should work right?
>> 
>> No, again, this would be banned. You are using a label (a thing that ends in 
>> a colon) inside a tuple pattern (a thing between parenthesis that comes 
>> after "let").
>>  
>> It’s assigning the inner tuple to second while also creating two additional 
>> constants from the inner tuple. I know this is redundant and can be used as 
>> second.x, but this should work like right, because it’s nested tuple 
>> destructuring? If we’d use var instead of let then x would contain the value 
>> assigned from the inner tuple, but it would be completely independent from 
>> the new second tuple variable.
>> 
>> 
>> 
>> -- 
>> Adrian Zubarev
>> Sent with Airmail
>> 
>> Am 5. Mai 2017 um 08:04:07, Xiaodi Wu (xiaodi...@gmail.com) schrieb:
>> 
>>> let (first: a, second: (x: b, y: c)): (first: Int, second: (x: Int, y: 
>>> Int)) = tuple // fine, unaffected
>>> This would be banned. You are using labels (things ending with a colon) in 
>>> a pattern (the stuff that comes after the word "let").
>> 
> 
> ___
> 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

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

[Xiaodi Wu via swift-evolution]

On Fri, May 5, 2017 at 1:31 AM, Xiaodi Wu  wrote:

> On Fri, May 5, 2017 at 1:21 AM, Robert Widmann 
> wrote:
>
>> Those labels anchored the reordering algorithm.  They guaranteed that
>> structural typing thing I brought up where you had to consume all the
>> labels in the type signature before you could continue, but that was where
>> their semantic value ended.  Given an ordering invariant, what matters are
>> the names *you* give to the values in the pattern.  Not the names given
>> in, say, the return value of the function - which as part of the type are
>> supposed to be irrelevant anyways.
>>
>
> There's more to Swift's syntax than what's solely required for the
> compiler to parse it. There are also the bits we put in to help humans
> write correct code.
>
> This is one reason why SE-0111 was revised to permit "cosmetic" labels for
> functions after their type system significance was removed. With respect to
> tuples, I fully understand that if you remove the ability to reorder
> indices of a tuple, labels in tuple patterns won't "do" anything--other
> than assert that the poor human who's writing them has the tuple elements
> in the right order. But that's important. That's valuable.
>

Put concretely:

```
let tuple = (x: 1, y: 2)

// I, silly human, mistakenly think the elements in the tuple are
// `y` first, then `x`. I'm a confused human. Now I write:

let (y: y, x: x) = tuple
// Currently, does the right thing, even though I'm confused.

let (y: y, x: x) = tuple
// Without tuple reordering, this produces an error, which corrects my
confusion.

let (y, x) = tuple
// Oops. I'm out of luck.
```

Enum cases are a different kettle of fish since the last round of proposals
>> (specifically SE-0155).  Associated value clauses are no longer tuples.
>>
>> Thank you for digging up that blog about this too.  I hadn't seen that
>> before I went into this - it came up because of code review related to some
>> fallout from SE-110.
>>
>> ~Robert Widmann
>>
>> 2017/05/05 2:09、Xiaodi Wu  のメッセージ:
>>
>> On Fri, May 5, 2017 at 1:01 AM, Robert Widmann 
>> wrote:
>>
>>>
>>>
>>> ~Robert Widmann
>>>
>>> 2017/05/05 1:42、Xiaodi Wu  のメッセージ:
>>>
>>> On Fri, May 5, 2017 at 00:17 Robert Widmann 
>>> wrote:
>>>
 On the contrary, this is precisely what it means to deprecate tuple
 shuffles.  You can’t map common parlance onto this term; the proposal and
 the Twitter thread weren’t merely about reordering arguments.

>>>
>>> Let's be clear: _all_ of your examples of "shuffles" in the proposal
>>> involve reordering. You defined a tuple shuffle as such: "an undocumented
>>> feature of Swift in which one can re-order the indices of a tuple" If
>>> you intend to propose a broader change, it is grossly misleading to write
>>> it up in this way.
>>>
>>>
>>> They are both modeled by shuffles.  And we are spinning off into
>>> semantic weeds I'd rather not spin off into.  The core of your
>>> counterargument is the pattern change being bad for business.  Let's
>>> discuss that.
>>>
>>>
>>> but it is entirely another ballgame to remove labels from tuple patterns
 altogether.


 It’s really not.  Let me demonstrate:

 To be clear, are you proposing the prohibition of *adding or removing*
> labels as well? A previous discussion on tuple shuffling on this list saw
> consensus that assigning a value of type (label1: T, label2: U) to a
> variable of type (T, U) and vice versa should absolutely be supported,
> whether or not reordering is permitted.


 I am not proposing any changes to switching parameter labels through
 well-typed re-assignments.  This is absolutely still going to be allowed:

 var z : (Int, Int) = (0, 0)
 var w : (x : Int, y : Int) = (5, 10)
 z = w
 w = z

 This is modeled internally with a tuple shuffle, but not the kind of
 shuffle I’m interested in banning.  It’s a far simpler kind of

>>>
>>> What is your proposed behavior for the following code?
>>>
>>> ```
>>> let x: (r: Int, g: Int, b: Int, a: Int) = (255, 255, 255, 0)
>>> let y: (a: Int, r: Int, g: Int, b: Int) = x
>>>
>>> print(y.a) // currently, prints "0"
>>> ```
>>>
>>> Either you are proposing only to remove labels from tuple patterns,
>>> which does not at all prohibit reordering, or you are proposing to prohibit
>>> reordering, in which case this code has an error--or it doesn't and you've
>>> instead _silently_ changed the behavior of existing code. One can live with
>>> warnings and even errors, but a silent change to existing code is the stuff
>>> of nightmares, and I would be strongly opposed to that.
>>>
>>>
>>> This is a reordering.  Banned.  End of story.  This code is fragile and
>>> demonstrates a key reason why we need to enforce an ordering invariant.
>>>
>>>
>>>

 And how about 

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

[Adrian Zubarev via swift-evolution]

I’m aware what a label is, I just had a small misunderstanding about nested 
destructuring. ;-)

Issue solved for me.

let (a, b /* inner tuple */) = tuple

let (_, (x, y)) = tuple
+1 I don’t mind this change at all.



-- 
Adrian Zubarev
Sent with Airmail

Am 5. Mai 2017 um 08:14:10, Xiaodi Wu (xiaodi...@gmail.com) schrieb:

On Fri, May 5, 2017 at 1:12 AM, Adrian Zubarev 
 wrote:
Oh pardon, on the first glance I didn’t realized the issue with that example.

Here is an updated example that would work:

let (first, second: (x, y)): (first: Int, second: (x: Int, y: Int)) = tuple
This should work right?

No, again, this would be banned. You are using a label (a thing that ends in a 
colon) inside a tuple pattern (a thing between parenthesis that comes after 
"let").
 
It’s assigning the inner tuple to second while also creating two additional 
constants from the inner tuple. I know this is redundant and can be used as 
second.x, but this should work like right, because it’s nested tuple 
destructuring? If we’d use var instead of let then x would contain the value 
assigned from the inner tuple, but it would be completely independent from the 
new second tuple variable.



-- 
Adrian Zubarev
Sent with Airmail

Am 5. Mai 2017 um 08:04:07, Xiaodi Wu (xiaodi...@gmail.com) schrieb:

let (first: a, second: (x: b, y: c)): (first: Int, second: (x: Int, y: Int)) = 
tuple // fine, unaffected
This would be banned. You are using labels (things ending with a colon) in a 
pattern (the stuff that comes after the word "let").

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

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

[Xiaodi Wu via swift-evolution]

On Fri, May 5, 2017 at 1:21 AM, Robert Widmann 
wrote:

> Those labels anchored the reordering algorithm.  They guaranteed that
> structural typing thing I brought up where you had to consume all the
> labels in the type signature before you could continue, but that was where
> their semantic value ended.  Given an ordering invariant, what matters are
> the names *you* give to the values in the pattern.  Not the names given
> in, say, the return value of the function - which as part of the type are
> supposed to be irrelevant anyways.
>

There's more to Swift's syntax than what's solely required for the compiler
to parse it. There are also the bits we put in to help humans write correct
code.

This is one reason why SE-0111 was revised to permit "cosmetic" labels for
functions after their type system significance was removed. With respect to
tuples, I fully understand that if you remove the ability to reorder
indices of a tuple, labels in tuple patterns won't "do" anything--other
than assert that the poor human who's writing them has the tuple elements
in the right order. But that's important. That's valuable.

Enum cases are a different kettle of fish since the last round of proposals
> (specifically SE-0155).  Associated value clauses are no longer tuples.
>
> Thank you for digging up that blog about this too.  I hadn't seen that
> before I went into this - it came up because of code review related to some
> fallout from SE-110.
>
> ~Robert Widmann
>
> 2017/05/05 2:09、Xiaodi Wu  のメッセージ:
>
> On Fri, May 5, 2017 at 1:01 AM, Robert Widmann 
> wrote:
>
>>
>>
>> ~Robert Widmann
>>
>> 2017/05/05 1:42、Xiaodi Wu  のメッセージ:
>>
>> On Fri, May 5, 2017 at 00:17 Robert Widmann 
>> wrote:
>>
>>> On the contrary, this is precisely what it means to deprecate tuple
>>> shuffles.  You can’t map common parlance onto this term; the proposal and
>>> the Twitter thread weren’t merely about reordering arguments.
>>>
>>
>> Let's be clear: _all_ of your examples of "shuffles" in the proposal
>> involve reordering. You defined a tuple shuffle as such: "an undocumented
>> feature of Swift in which one can re-order the indices of a tuple" If
>> you intend to propose a broader change, it is grossly misleading to write
>> it up in this way.
>>
>>
>> They are both modeled by shuffles.  And we are spinning off into semantic
>> weeds I'd rather not spin off into.  The core of your counterargument is
>> the pattern change being bad for business.  Let's discuss that.
>>
>>
>> but it is entirely another ballgame to remove labels from tuple patterns
>>> altogether.
>>>
>>>
>>> It’s really not.  Let me demonstrate:
>>>
>>> To be clear, are you proposing the prohibition of *adding or removing*
 labels as well? A previous discussion on tuple shuffling on this list saw
 consensus that assigning a value of type (label1: T, label2: U) to a
 variable of type (T, U) and vice versa should absolutely be supported,
 whether or not reordering is permitted.
>>>
>>>
>>> I am not proposing any changes to switching parameter labels through
>>> well-typed re-assignments.  This is absolutely still going to be allowed:
>>>
>>> var z : (Int, Int) = (0, 0)
>>> var w : (x : Int, y : Int) = (5, 10)
>>> z = w
>>> w = z
>>>
>>> This is modeled internally with a tuple shuffle, but not the kind of
>>> shuffle I’m interested in banning.  It’s a far simpler kind of
>>>
>>
>> What is your proposed behavior for the following code?
>>
>> ```
>> let x: (r: Int, g: Int, b: Int, a: Int) = (255, 255, 255, 0)
>> let y: (a: Int, r: Int, g: Int, b: Int) = x
>>
>> print(y.a) // currently, prints "0"
>> ```
>>
>> Either you are proposing only to remove labels from tuple patterns, which
>> does not at all prohibit reordering, or you are proposing to prohibit
>> reordering, in which case this code has an error--or it doesn't and you've
>> instead _silently_ changed the behavior of existing code. One can live with
>> warnings and even errors, but a silent change to existing code is the stuff
>> of nightmares, and I would be strongly opposed to that.
>>
>>
>> This is a reordering.  Banned.  End of story.  This code is fragile and
>> demonstrates a key reason why we need to enforce an ordering invariant.
>>
>>
>>
>>>
>>> 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 

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

[Robert Widmann via swift-evolution]

Those labels anchored the reordering algorithm.  They guaranteed that 
structural typing thing I brought up where you had to consume all the labels in 
the type signature before you could continue, but that was where their semantic 
value ended.  Given an ordering invariant, what matters are the names you give 
to the values in the pattern.  Not the names given in, say, the return value of 
the function - which as part of the type are supposed to be irrelevant anyways.

Enum cases are a different kettle of fish since the last round of proposals 
(specifically SE-0155).  Associated value clauses are no longer tuples.

Thank you for digging up that blog about this too.  I hadn't seen that before I 
went into this - it came up because of code review related to some fallout from 
SE-110.

~Robert Widmann

2017/05/05 2:09、Xiaodi Wu  のメッセージ:

>> On Fri, May 5, 2017 at 1:01 AM, Robert Widmann  
>> wrote:
>> 
>> 
>> ~Robert Widmann
>> 
>> 2017/05/05 1:42、Xiaodi Wu  のメッセージ:
>> 
 On Fri, May 5, 2017 at 00:17 Robert Widmann  
 wrote:
>>> 
 On the contrary, this is precisely what it means to deprecate tuple 
 shuffles.  You can’t map common parlance onto this term; the proposal and 
 the Twitter thread weren’t merely about reordering arguments.
>>> 
>>> Let's be clear: _all_ of your examples of "shuffles" in the proposal 
>>> involve reordering. You defined a tuple shuffle as such: "an undocumented 
>>> feature of Swift in which one can re-order the indices of a tuple" If 
>>> you intend to propose a broader change, it is grossly misleading to write 
>>> it up in this way.
>> 
>> They are both modeled by shuffles.  And we are spinning off into semantic 
>> weeds I'd rather not spin off into.  The core of your counterargument is the 
>> pattern change being bad for business.  Let's discuss that. 
>> 
>>> 
> but it is entirely another ballgame to remove labels from tuple patterns 
> altogether.
 
 It’s really not.  Let me demonstrate:
 
>> To be clear, are you proposing the prohibition of *adding or removing* 
>> labels as well? A previous discussion on tuple shuffling on this list 
>> saw consensus that assigning a value of type (label1: T, label2: U) to a 
>> variable of type (T, U) and vice versa should absolutely be supported, 
>> whether or not reordering is permitted.
 
 I am not proposing any changes to switching parameter labels through 
 well-typed re-assignments.  This is absolutely still going to be allowed:
 
 var z : (Int, Int) = (0, 0)
 var w : (x : Int, y : Int) = (5, 10)
 z = w
 w = z
 
 This is modeled internally with a tuple shuffle, but not the kind of 
 shuffle I’m interested in banning.  It’s a far simpler kind of 
>>> 
>>> What is your proposed behavior for the following code?
>>> 
>>> ```
>>> let x: (r: Int, g: Int, b: Int, a: Int) = (255, 255, 255, 0)
>>> let y: (a: Int, r: Int, g: Int, b: Int) = x
>>> 
>>> print(y.a) // currently, prints "0"
>>> ```
>>> 
>>> Either you are proposing only to remove labels from tuple patterns, which 
>>> does not at all prohibit reordering, or you are proposing to prohibit 
>>> reordering, in which case this code has an error--or it doesn't and you've 
>>> instead _silently_ changed the behavior of existing code. One can live with 
>>> warnings and even errors, but a silent change to existing code is the stuff 
>>> of nightmares, and I would be strongly opposed to that.
>> 
>> This is a reordering.  Banned.  End of story.  This code is fragile and 
>> demonstrates a key reason why we need to enforce an ordering invariant.
>> 
>>>  
 
>> And how about *restating* existing labels without any adding or 
>> removing? To be clear:
>> 
>> ```
>> let (partialValue: v, overflow: o) = 42.addingReportingOverflow(42)
>> ```
>> 
>> ...involves absolutely no changes in labels whatsoever. The return type 
>> is (partialValue: Int, overflow: ArithmeticOverflow).
 
 That, however, is a kind of shuffle I intend to deprecate here.  This kind 
 of pattern is subject to the “arcane syntax” part of the proposal.
 
>> 
>> Either one of these scenarios is commonly used, and it is astonishing to 
>> me that they would be eliminated.
 
 Do you have proof of that claim? I have never seen the relevant kinds of 
 tuple shuffle used before, and I doubt you have either before today.
>>> 
>>> Huh? I use it pervasively. Currently, writing out labels during 
>>> destructuring guarantees that, even if I've incorrectly memorized the order 
>>> of the values in a tuple, the tuple is still destructured as I expect. And 
>>> if reordering were not a feature of Swift, I would still write out these 
>>> labels. In that case, it would be a static assertion that destructuring is 
>>> happening in the expected order. That is, if 

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

[Xiaodi Wu via swift-evolution]

On Fri, May 5, 2017 at 1:12 AM, Adrian Zubarev <
adrian.zuba...@devandartist.com> wrote:

> Oh pardon, on the first glance I didn’t realized the issue with that
> example.
>
> Here is an updated example that would work:
>
> let (first, second: (x, y)): (first: Int, second: (x: Int, y: Int)) = tuple
>
> This should work right?
>
No, again, this would be banned. You are using a label (a thing that ends
in a colon) inside a tuple pattern (a thing between parenthesis that comes
after "let").


> It’s assigning the inner tuple to second while also creating two
> additional constants from the inner tuple. I know this is redundant and can
> be used as second.x, but this should work like right, because it’s nested
> tuple destructuring? If we’d use var instead of let then x would contain
> the value assigned from the inner tuple, but it would be completely
> independent from the new second tuple variable.
>
>
>
> --
> Adrian Zubarev
> Sent with Airmail
>
> Am 5. Mai 2017 um 08:04:07, Xiaodi Wu (xiaodi...@gmail.com) schrieb:
>
> let (first: a, second: (x: b, y: c)): (first: Int, second: (x: Int, y: Int)) 
> = tuple // fine, unaffected
>
> This would be banned. You are using labels (things ending with a colon) in
> a pattern (the stuff that comes after the word "let").
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Adrian Zubarev via swift-evolution]

Oh pardon, on the first glance I didn’t realized the issue with that example.

Here is an updated example that would work:

let (first, second: (x, y)): (first: Int, second: (x: Int, y: Int)) = tuple
This should work right? It’s assigning the inner tuple to second while also 
creating two additional constants from the inner tuple. I know this is 
redundant and can be used as second.x, but this should work like right, because 
it’s nested tuple destructuring? If we’d use var instead of let then x would 
contain the value assigned from the inner tuple, but it would be completely 
independent from the new second tuple variable.



-- 
Adrian Zubarev
Sent with Airmail

Am 5. Mai 2017 um 08:04:07, Xiaodi Wu (xiaodi...@gmail.com) schrieb:

let (first: a, second: (x: b, y: c)): (first: Int, second: (x: Int, y: Int)) = 
tuple // fine, unaffected
This would be banned. You are using labels (things ending with a colon) in a 
pattern (the stuff that comes after the word "let").
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Xiaodi Wu via swift-evolution]

On Fri, May 5, 2017 at 1:01 AM, Robert Widmann 
wrote:

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

We can agree that relabeling can be abused, but it does not stand to reason
that labeling (i.e. the correct, unchanged label) has no role in tuple
patterns. Again, it serves as 

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

[Xiaodi Wu via swift-evolution]

On Fri, May 5, 2017 at 1:00 AM, Adrian Zubarev <
adrian.zuba...@devandartist.com> wrote:

> Just to double check, here is the updated version of my code snippet on
> how it would look like if this proposal will be accepted.
>
> let a: (x: Int, y: Int) = (1, 2)
> var b: (y: Int, x: Int) = a
>
> This would be banned. It involves reordering arguments.


> Label swap while destructuring:
>
> let tuple: (first: Int, second: (x: Int, y: Int)) = (0, (1, 2))
>
> let (first: a, second: (x: b, y: c)): (first: Int, second: (x: Int, y: Int)) 
> = tuple // fine, unaffected
>
> This would be banned. You are using labels (things ending with a colon) in
a pattern (the stuff that comes after the word "let").

let (second: (x: b, y: c), first: a): (second: (x: Int, y: Int),
first: Int) = tuple // will the rendering be banned or not?
>
> This would also be banned.


>  Is this correct now?
>
>
>
> --
> Adrian Zubarev
> Sent with Airmail
>
> Am 5. Mai 2017 um 07:53:51, Xiaodi Wu (xiaodi...@gmail.com) schrieb:
>
> On Fri, May 5, 2017 at 12:52 AM, Adrian Zubarev <
> adrian.zuba...@devandartist.com> wrote:
>
>> Eliminating all labels would mean that even the first example from my
>> last post will be banned.
>>
> No, not eliminating all labels from tuples, but from tuple _patterns_.
>
>
>> Is there any difference from labels in tuple types and labels in tuples
>> themselves?
>>
>> Personally I would not support the removal of labels from tuple types,
>> because it’s a very useful feature that replaces indexed access like
>> myTuple.1 to a more readable counterpart myTuple.somethingSpecial.
>>
>> Am I still missing something out?
>>
>>
>> --
>> Adrian Zubarev
>> Sent with Airmail
>>
>> Am 5. Mai 2017 um 07:43:49, Xiaodi Wu (xiaodi...@gmail.com) schrieb:
>>
>> On Fri, May 5, 2017 at 12:42 AM, Adrian Zubarev via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>> 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
>>>
>>>
>> No, I thought this was what Robert was proposing, but he is proposing the
>> elimination of all labels in tuple patterns. Your second example would be
>> banned.
>>
>>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Robert Widmann via swift-evolution]

~Robert Widmann

2017/05/05 1:42、Xiaodi Wu  のメッセージ:

>> On Fri, May 5, 2017 at 00:17 Robert Widmann  wrote:
> 
>> On the contrary, this is precisely what it means to deprecate tuple 
>> shuffles.  You can’t map common parlance onto this term; the proposal and 
>> the Twitter thread weren’t merely about reordering arguments.
> 
> Let's be clear: _all_ of your examples of "shuffles" in the proposal involve 
> reordering. You defined a tuple shuffle as such: "an undocumented feature of 
> Swift in which one can re-order the indices of a tuple" If you intend to 
> propose a broader change, it is grossly misleading to write it up in this way.

They are both modeled by shuffles.  And we are spinning off into semantic weeds 
I'd rather not spin off into.  The core of your counterargument is the pattern 
change being bad for business.  Let's discuss that. 

> 
>>> but it is entirely another ballgame to remove labels from tuple patterns 
>>> altogether.
>> 
>> It’s really not.  Let me demonstrate:
>> 
 To be clear, are you proposing the prohibition of *adding or removing* 
 labels as well? A previous discussion on tuple shuffling on this list saw 
 consensus that assigning a value of type (label1: T, label2: U) to a 
 variable of type (T, U) and vice versa should absolutely be supported, 
 whether or not reordering is permitted.
>> 
>> I am not proposing any changes to switching parameter labels through 
>> well-typed re-assignments.  This is absolutely still going to be allowed:
>> 
>> var z : (Int, Int) = (0, 0)
>> var w : (x : Int, y : Int) = (5, 10)
>> z = w
>> w = z
>> 
>> This is modeled internally with a tuple shuffle, but not the kind of shuffle 
>> I’m interested in banning.  It’s a far simpler kind of 
> 
> What is your proposed behavior for the following code?
> 
> ```
> let x: (r: Int, g: Int, b: Int, a: Int) = (255, 255, 255, 0)
> let y: (a: Int, r: Int, g: Int, b: Int) = x
> 
> print(y.a) // currently, prints "0"
> ```
> 
> Either you are proposing only to remove labels from tuple patterns, which 
> does not at all prohibit reordering, or you are proposing to prohibit 
> reordering, in which case this code has an error--or it doesn't and you've 
> instead _silently_ changed the behavior of existing code. One can live with 
> warnings and even errors, but a silent change to existing code is the stuff 
> of nightmares, and I would be strongly opposed to that.

This is a reordering.  Banned.  End of story.  This code is fragile and 
demonstrates a key reason why we need to enforce an ordering invariant.

>  
>> 
 And how about *restating* existing labels without any adding or removing? 
 To be clear:
 
 ```
 let (partialValue: v, overflow: o) = 42.addingReportingOverflow(42)
 ```
 
 ...involves absolutely no changes in labels whatsoever. The return type is 
 (partialValue: Int, overflow: ArithmeticOverflow).
>> 
>> That, however, is a kind of shuffle I intend to deprecate here.  This kind 
>> of pattern is subject to the “arcane syntax” part of the proposal.
>> 
 
 Either one of these scenarios is commonly used, and it is astonishing to 
 me that they would be eliminated.
>> 
>> Do you have proof of that claim? I have never seen the relevant kinds of 
>> tuple shuffle used before, and I doubt you have either before today.
> 
> Huh? I use it pervasively. Currently, writing out labels during destructuring 
> guarantees that, even if I've incorrectly memorized the order of the values 
> in a tuple, the tuple is still destructured as I expect. And if reordering 
> were not a feature of Swift, I would still write out these labels. In that 
> case, it would be a static assertion that destructuring is happening in the 
> expected order. That is, if I try to destructure a tuple of type (r: Int, g: 
> Int, b: Int, a: Int) and accidentally write 'let (a: alpha, r: _, g: green, 
> b: _) = ...', I'd get an error and find my mistake at compile time.
> 
> The whole point of having labels in the first place is clarity at the point 
> of use. Just as SE-0111 will need revision because it removed a key 
> documentation use for argument labels, forbidding labels in tuple patterns 
> would make the same mistake for tuples.

The intent at the time may have been to treat tuples as a kind of 
structurally-typed thing, but shadowing concerns and reordering in patterns 
means this kind of relabeling can be abused and shouldn't be trusted as a kind 
of structural invariant in a pattern - as we seem to agree.  To me, labels in 
tuple types provide a means of defining custom projections out of the tuple, 
nothing more.  In patterns, I don't see a reason for them.

> 
>> 
>> ~Robert Widmann
>> 
>>> On May 5, 2017, at 12:53 AM, Xiaodi Wu  wrote:
>>> 
>>> Ah, I see from your proposed grammar update: you're proposing to prohibit 
>>> the use of labels entirely in a tuple pattern.
>>> 
>>> This 

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

[Adrian Zubarev via swift-evolution]

Just to double check, here is the updated version of my code snippet on how it 
would look like if this proposal will be accepted.

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

let tuple: (first: Int, second: (x: Int, y: Int)) = (0, (1, 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 // will the rendering be banned or not?
Is this correct now?



-- 
Adrian Zubarev
Sent with Airmail

Am 5. Mai 2017 um 07:53:51, Xiaodi Wu (xiaodi...@gmail.com) schrieb:

On Fri, May 5, 2017 at 12:52 AM, Adrian Zubarev 
 wrote:
Eliminating all labels would mean that even the first example from my last post 
will be banned.

No, not eliminating all labels from tuples, but from tuple _patterns_.
 
Is there any difference from labels in tuple types and labels in tuples 
themselves?

Personally I would not support the removal of labels from tuple types, because 
it’s a very useful feature that replaces indexed access like myTuple.1 to a 
more readable counterpart myTuple.somethingSpecial.

Am I still missing something out?



-- 
Adrian Zubarev
Sent with Airmail

Am 5. Mai 2017 um 07:43:49, Xiaodi Wu (xiaodi...@gmail.com) schrieb:

On Fri, May 5, 2017 at 12:42 AM, Adrian Zubarev via swift-evolution 
 wrote:
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

No, I thought this was what Robert was proposing, but he is proposing the 
elimination of all labels in tuple patterns. Your second example would be 
banned.


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

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

[Xiaodi Wu via swift-evolution]

On Fri, May 5, 2017 at 12:42 AM, Xiaodi Wu  wrote:

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

I should add, it boggles the mind that you would claim that people will
have never heard of this before today. It's been discussed _on this very
list_!
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Xiaodi Wu via swift-evolution]

On Fri, May 5, 2017 at 12:54 AM, David Hart  wrote:

>
> On 5 May 2017, at 07:17, Robert Widmann via swift-evolution <
> swift-evolution@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

~Robert Widmann
>
> On May 5, 2017, at 12:53 AM, Xiaodi Wu  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  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 
>> 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  のメッセージ:
>>>
>>> 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 

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

[David Hart via swift-evolution]

> On 5 May 2017, at 07:17, Robert Widmann via swift-evolution 
>  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.

> ~Robert Widmann
> 
>> On May 5, 2017, at 12:53 AM, Xiaodi Wu  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  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  
 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  のメッセージ:
 
> 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 
>>  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 
>> 

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

[Xiaodi Wu via swift-evolution]

On Fri, May 5, 2017 at 12:52 AM, Adrian Zubarev <
adrian.zuba...@devandartist.com> wrote:

> Eliminating all labels would mean that even the first example from my last
> post will be banned.
>
No, not eliminating all labels from tuples, but from tuple _patterns_.


> Is there any difference from labels in tuple types and labels in tuples
> themselves?
>
> Personally I would not support the removal of labels from tuple types,
> because it’s a very useful feature that replaces indexed access like
> myTuple.1 to a more readable counterpart myTuple.somethingSpecial.
>
> Am I still missing something out?
>
>
>
> --
> Adrian Zubarev
> Sent with Airmail
>
> Am 5. Mai 2017 um 07:43:49, Xiaodi Wu (xiaodi...@gmail.com) schrieb:
>
> On Fri, May 5, 2017 at 12:42 AM, Adrian Zubarev via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> 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
>>
>>
> No, I thought this was what Robert was proposing, but he is proposing the
> elimination of all labels in tuple patterns. Your second example would be
> banned.
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Adrian Zubarev via swift-evolution]

Eliminating all labels would mean that even the first example from my last post 
will be banned.

Is there any difference from labels in tuple types and labels in tuples 
themselves?

Personally I would not support the removal of labels from tuple types, because 
it’s a very useful feature that replaces indexed access like myTuple.1 to a 
more readable counterpart myTuple.somethingSpecial.

Am I still missing something out?



-- 
Adrian Zubarev
Sent with Airmail

Am 5. Mai 2017 um 07:43:49, Xiaodi Wu (xiaodi...@gmail.com) schrieb:

On Fri, May 5, 2017 at 12:42 AM, Adrian Zubarev via swift-evolution 
 wrote:
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

No, I thought this was what Robert was proposing, but he is proposing the 
elimination of all labels in tuple patterns. Your second example would be 
banned.

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

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

[Xiaodi Wu via swift-evolution]

On Fri, May 5, 2017 at 12:42 AM, Adrian Zubarev via swift-evolution <
swift-evolution@swift.org> wrote:

> 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
>
>
No, I thought this was what Robert was proposing, but he is proposing the
elimination of all labels in tuple patterns. Your second example would be
banned.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Xiaodi Wu via swift-evolution]

On Fri, May 5, 2017 at 00:17 Robert Widmann 
wrote:

> On the contrary, this is precisely what it means to deprecate tuple
> shuffles.  You can’t map common parlance onto this term; the proposal and
> the Twitter thread weren’t merely about reordering arguments.
>

Let's be clear: _all_ of your examples of "shuffles" in the proposal
involve reordering. You defined a tuple shuffle as such: "an undocumented
feature of Swift in which one can re-order the indices of a tuple" If
you intend to propose a broader change, it is grossly misleading to write
it up in this way.

but it is entirely another ballgame to remove labels from tuple patterns
> altogether.
>
>
> It’s really not.  Let me demonstrate:
>
> To be clear, are you proposing the prohibition of *adding or removing*
>> labels as well? A previous discussion on tuple shuffling on this list saw
>> consensus that assigning a value of type (label1: T, label2: U) to a
>> variable of type (T, U) and vice versa should absolutely be supported,
>> whether or not reordering is permitted.
>
>
> I am not proposing any changes to switching parameter labels through
> well-typed re-assignments.  This is absolutely still going to be allowed:
>
> var z : (Int, Int) = (0, 0)
> var w : (x : Int, y : Int) = (5, 10)
> z = w
> w = z
>
> This is modeled internally with a tuple shuffle, but not the kind of
> shuffle I’m interested in banning.  It’s a far simpler kind of
>

What is your proposed behavior for the following code?

```
let x: (r: Int, g: Int, b: Int, a: Int) = (255, 255, 255, 0)
let y: (a: Int, r: Int, g: Int, b: Int) = x

print(y.a) // currently, prints "0"
```

Either you are proposing only to remove labels from tuple patterns, which
does not at all prohibit reordering, or you are proposing to prohibit
reordering, in which case this code has an error--or it doesn't and you've
instead _silently_ changed the behavior of existing code. One can live with
warnings and even errors, but a silent change to existing code is the stuff
of nightmares, and I would be strongly opposed to that.


>
> And how about *restating* existing labels without any adding or removing?
>> To be clear:
>>
>> ```
>> let (partialValue: v, overflow: o) = 42.addingReportingOverflow(42)
>> ```
>>
>> ...involves absolutely no changes in labels whatsoever. The return type
>> is (partialValue: Int, overflow: ArithmeticOverflow).
>>
>
> That, however, is a kind of shuffle I intend to deprecate here.  This kind
> of pattern is subject to the “arcane syntax” part of the proposal.
>
>
>> Either one of these scenarios is commonly used, and it is astonishing to
>> me that they would be eliminated.
>
>
> Do you have proof of that claim? I have never seen the relevant kinds of
> tuple shuffle used before, and I doubt you have either before today.
>

Huh? I use it pervasively. Currently, writing out labels during
destructuring guarantees that, even if I've incorrectly memorized the order
of the values in a tuple, the tuple is still destructured as I expect. And
if reordering were not a feature of Swift, I would still write out these
labels. In that case, it would be a static assertion that destructuring is
happening in the expected order. That is, if I try to destructure a tuple
of type (r: Int, g: Int, b: Int, a: Int) and accidentally write 'let (a:
alpha, r: _, g: green, b: _) = ...', I'd get an error and find my mistake
at compile time.

The whole point of having labels in the first place is clarity at the point
of use. Just as SE-0111 will need revision because it removed a key
documentation use for argument labels, forbidding labels in tuple patterns
would make the same mistake for tuples.



> ~Robert Widmann
>
> On May 5, 2017, at 12:53 AM, Xiaodi Wu  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  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) = 

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

[Adrian Zubarev via swift-evolution]

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

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

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

[Robert Widmann via swift-evolution]

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

~Robert Widmann

> On May 5, 2017, at 1:16 AM, Adrian Zubarev  
> 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- 
>> 
>> 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 )
>> 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.
>> 
>>  
>> 

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

[Robert Widmann via swift-evolution]

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  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  > 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  > 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 > 
> のメッセージ:
> 
>> 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 
>> > 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- 
>> 

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

[Adrian Zubarev via swift-evolution]

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-
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 )
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
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Xiaodi Wu via swift-evolution]

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  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 
> 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  のメッセージ:
>>
>> 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-
>>>
>>> 
>>>- 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 = 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
>>> , 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 

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

[Xiaodi Wu via swift-evolution]

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 
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  のメッセージ:
>
> 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-
>>
>> 
>>- 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 = 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
>> , 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.
>>
>> 

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

[Robert Widmann via swift-evolution]

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  のメッセージ:

> 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 
>>  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-
>> 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 )
>> 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
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Xiaodi Wu via swift-evolution]

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-
>
> 
>- 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 = 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
> , 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 )
> 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
>

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

[Jose Cheyo Jimenez via swift-evolution]

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 
>  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-
> 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 )
> 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
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Robert Widmann via swift-evolution]

- 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 
.  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 
>  wrote:
> 
> 
>> On 5 May 2017, at 12:27, Félix Cloutier via swift-evolution 
>>  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

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

[Tony Arnold via swift-evolution]

> On 5 May 2017, at 12:27, Félix Cloutier via swift-evolution 
>  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

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

[Félix Cloutier via swift-evolution]

Why?

> Le 4 mai 2017 à 19:14, Robert Widmann via swift-evolution 
>  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 
> .
> 
> Thanks!
> 
> ~Robert Widmann
> 
> Deprecate Tuple Shuffles
> 
> Proposal: SE- 
> 
> 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 )
> 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

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

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

[Robert Widmann via swift-evolution]

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- 

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