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 <[email protected]> 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 <[email protected] > <mailto:[email protected]>> 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 <[email protected] > <mailto:[email protected]>> 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 <[email protected] <mailto:[email protected]>> > のメッセージ: > >> 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 >> <[email protected] <mailto:[email protected]>> 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 >> [email protected] <mailto:[email protected]> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
