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