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

Fri May 5 00:56:45 CDT 2017

On Fri, May 5, 2017 at 12:54 AM, David Hart <david at hartbit.com> wrote:

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

If you google "Swift tuple destructuring," it's demonstrated in the third
link you can click on. The article is even titled "best practices":

https://github.com/terhechte/appventure-blog/blob/master/resources/posts/2015-07-19-tuples-swift-advanced-usage-best-practices.org

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