I can't think of a single time when I would need a tuple shuffle but I don't really work with tuples much. It would be great to hear other people's usage of this feature.
I did not know that types could be overloaded with values. That was very surprising to me. Honestly I think that is the issue here. Not sure what can be done about it. let Int = 5 // works let Void = "what?" // works. > On May 4, 2017, at 7:14 PM, 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