> On 5 May 2017, at 07:56, Xiaodi Wu <xiaodi...@gmail.com> wrote: > > On Fri, May 5, 2017 at 12:54 AM, David Hart <da...@hartbit.com > <mailto:da...@hartbit.com>> wrote: > > On 5 May 2017, at 07:17, Robert Widmann via swift-evolution > <swift-evolution@swift.org <mailto: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 > > <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 <xiaodi...@gmail.com >>> <mailto: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 >>> <mailto: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 >>> <mailto: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 >>> <mailto: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 <mailto:swift-evolution@swift.org>> wrote: >>>> Hi all, >>>> >>>> So sorry that this proposal comes so late in the game, but I feel it’s too >>>> important not to bring it to the attention of the community now. Attached >>>> is a proposal to deprecate a language feature many of you will probably >>>> have never had the chance to use: Tuple Shuffles. I’ve attached a copy of >>>> the first draft of the proposal below, but the latest copy can be read on >>>> Github <https://github.com/apple/swift-evolution/pull/705/files>. >>>> >>>> Thanks! >>>> >>>> ~Robert Widmann >>>> >>>> Deprecate Tuple Shuffles >>>> >>>> Proposal: SE-NNNN >>>> <https://github.com/CodaFi/swift-evolution/blob/8eaf320b3c2a117909fc0269c398e89c033a4b9f/proposals/NNNN-filename.md> >>>> Authors: Robert Widmann <https://github.com/codafi> >>>> Review Manager: TBD >>>> Status: Awaiting review >>>> >>>> <https://github.com/CodaFi/swift-evolution/blob/8eaf320b3c2a117909fc0269c398e89c033a4b9f/proposals/NNNN-deprecate-tuple-shuffles.md#introduction>Introduction >>>> >>>> This proposal seeks the deprecation of a little-known feature of Swift >>>> called a "Tuple Shuffle". >>>> >>>> >>>> <https://github.com/CodaFi/swift-evolution/blob/8eaf320b3c2a117909fc0269c398e89c033a4b9f/proposals/NNNN-deprecate-tuple-shuffles.md#motivation>Motivation >>>> >>>> A tuple-shuffle is an undocumented feature of Swift in which one can >>>> re-order the indices of a tuple by writing a pattern that describes a >>>> permutation in a syntax reminiscent of adding type-annotations to a >>>> parameter list: >>>> >>>> let a = (x: 1, y: 2) >>>> var b: (y: Int, x: Int) >>>> b = a >>>> It can be used to simultaneously destructure and reorder a tuple: >>>> >>>> let tuple = (first: 0, second: (x: 1, y: 2)) >>>> let (second: (x: b, y: c), first: a) = tuple >>>> It can also be used to map parameter labels out of order in a call >>>> expression: >>>> >>>> func foo(_ : (x : Int, y : Int)) {} >>>> foo((y: 5, x: 10)) // Valid >>>> Note that a tuple shuffle is distinct from a re-assignment through a tuple >>>> pattern. For example, this series of statements will continue to function >>>> as before: >>>> >>>> var x = 5 >>>> var y = 10 >>>> var z = 15 >>>> (z, y, x) = (x, z, y) >>>> Their inclusion in the language complicates every part of the compiler >>>> stack, uses a syntax that can be confused for type annotations >>>> <https://twitter.com/CodaFi_/status/860246169854894081>, contradicts the >>>> goals of earlier SE's (see SE-0060 >>>> <https://github.com/apple/swift-evolution/blob/9cf2685293108ea3efcbebb7ee6a8618b83d4a90/proposals/0060-defaulted-parameter-order.md>), >>>> and makes non-sensical patterns possible in surprising places. >>>> >>>> Take switch-statements, for example: >>>> >>>> switch ((0, 0), 0){ >>>> case (_ : let (y, z), _ : let s): () // We are forbidden from giving these >>>> patterns names other than "_" >>>> default: () >>>> } >>>> This proposal seeks to deprecate them in Swift 3 compatibility mode and >>>> enforce that deprecation as a hard error in Swift 4 to facilitate their >>>> eventual removal from the language. >>>> >>>> >>>> <https://github.com/CodaFi/swift-evolution/blob/8eaf320b3c2a117909fc0269c398e89c033a4b9f/proposals/NNNN-deprecate-tuple-shuffles.md#proposed-solution>Proposed >>>> solution >>>> >>>> Construction of Tuple Shuffle Expressions will become a warning in Swift 3 >>>> compatibility mode and will be a hard-error in Swift 4. >>>> >>>> >>>> <https://github.com/CodaFi/swift-evolution/blob/8eaf320b3c2a117909fc0269c398e89c033a4b9f/proposals/NNNN-deprecate-tuple-shuffles.md#detailed-design>Detailed >>>> design >>>> >>>> In addition to the necessary diagnostics, the grammar will be ammended to >>>> simplify the following productions: >>>> >>>> tuple-pattern → (tuple-pattern-element-list <opt>) >>>> tuple-pattern-element-list → tuple-pattern-element | tuple-pattern-element >>>> , tuple-pattern-element-list >>>> - tuple-pattern-element → pattern | identifier:pattern >>>> + tuple-pattern-element → pattern >>>> >>>> <https://github.com/CodaFi/swift-evolution/blob/8eaf320b3c2a117909fc0269c398e89c033a4b9f/proposals/NNNN-deprecate-tuple-shuffles.md#impact-on-existing-code>Impact >>>> on Existing Code >>>> >>>> Because very little code is intentionally using Tuple Shuffles, impact on >>>> existing code will be negligible but not non-zero. >>>> >>>> >>>> <https://github.com/CodaFi/swift-evolution/blob/8eaf320b3c2a117909fc0269c398e89c033a4b9f/proposals/NNNN-deprecate-tuple-shuffles.md#alternatives-considered>Alternatives >>>> considered >>>> >>>> Continue to keep the architecture in place to facilitate this feature. >>>> _______________________________________________ >>>> swift-evolution mailing list >>>> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >> >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution> >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
