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