That is weird indeed, there is need of more argument labels, like argument labels back in stored closures and callbacks, not even less argument labels all around :/.
-1 as a corner case of the language throws the baby out with the bathwater. Sent from my iPhone > On 5 May 2017, at 05:53, Xiaodi Wu via swift-evolution > <[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]> 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]> >>> 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]> のメッセージ: >>> >>>> 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
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
