What others have noted, in addition to our Twitter thread, is that this proposal has revealed the need for diagnostics about shadowing. There are currently two boundaries in Swift along which we allow shadowing in the same scope: Function arguments and patterns. If we can close both of those loopholes I would be much less skittish about labels.
~Robert Widmann > On May 5, 2017, at 2:35 AM, Xiaodi Wu <xiaodi...@gmail.com> wrote: > > On Fri, May 5, 2017 at 1:31 AM, Xiaodi Wu <xiaodi...@gmail.com > <mailto:xiaodi...@gmail.com>> wrote: > On Fri, May 5, 2017 at 1:21 AM, Robert Widmann <devteam.cod...@gmail.com > <mailto:devteam.cod...@gmail.com>> wrote: > Those labels anchored the reordering algorithm. They guaranteed that > structural typing thing I brought up where you had to consume all the labels > in the type signature before you could continue, but that was where their > semantic value ended. Given an ordering invariant, what matters are the > names you give to the values in the pattern. Not the names given in, say, > the return value of the function - which as part of the type are supposed to > be irrelevant anyways. > > There's more to Swift's syntax than what's solely required for the compiler > to parse it. There are also the bits we put in to help humans write correct > code. > > This is one reason why SE-0111 was revised to permit "cosmetic" labels for > functions after their type system significance was removed. With respect to > tuples, I fully understand that if you remove the ability to reorder indices > of a tuple, labels in tuple patterns won't "do" anything--other than assert > that the poor human who's writing them has the tuple elements in the right > order. But that's important. That's valuable. > > Put concretely: > > ``` > let tuple = (x: 1, y: 2) > > // I, silly human, mistakenly think the elements in the tuple are > // `y` first, then `x`. I'm a confused human. Now I write: > > let (y: y, x: x) = tuple > // Currently, does the right thing, even though I'm confused. > > let (y: y, x: x) = tuple > // Without tuple reordering, this produces an error, which corrects my > confusion. > > let (y, x) = tuple > // Oops. I'm out of luck. > ``` > > Enum cases are a different kettle of fish since the last round of proposals > (specifically SE-0155). Associated value clauses are no longer tuples. > > Thank you for digging up that blog about this too. I hadn't seen that before > I went into this - it came up because of code review related to some fallout > from SE-110. > > ~Robert Widmann > > 2017/05/05 2:09、Xiaodi Wu <xiaodi...@gmail.com <mailto:xiaodi...@gmail.com>> > のメッセージ: > >> On Fri, May 5, 2017 at 1:01 AM, Robert Widmann <devteam.cod...@gmail.com >> <mailto:devteam.cod...@gmail.com>> wrote: >> >> >> ~Robert Widmann >> >> 2017/05/05 1:42、Xiaodi Wu <xiaodi...@gmail.com <mailto:xiaodi...@gmail.com>> >> のメッセージ: >> >>> On Fri, May 5, 2017 at 00:17 Robert Widmann <devteam.cod...@gmail.com >>> <mailto:devteam.cod...@gmail.com>> 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. >>> >>> Let's be clear: _all_ of your examples of "shuffles" in the proposal >>> involve reordering. You defined a tuple shuffle as such: "an undocumented >>> feature of Swift in which one can re-order the indices of a tuple...." If >>> you intend to propose a broader change, it is grossly misleading to write >>> it up in this way. >> >> They are both modeled by shuffles. And we are spinning off into semantic >> weeds I'd rather not spin off into. The core of your counterargument is the >> pattern change being bad for business. Let's discuss that. >> >>> >>>> 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 >>> >>> What is your proposed behavior for the following code? >>> >>> ``` >>> let x: (r: Int, g: Int, b: Int, a: Int) = (255, 255, 255, 0) >>> let y: (a: Int, r: Int, g: Int, b: Int) = x >>> >>> print(y.a) // currently, prints "0" >>> ``` >>> >>> Either you are proposing only to remove labels from tuple patterns, which >>> does not at all prohibit reordering, or you are proposing to prohibit >>> reordering, in which case this code has an error--or it doesn't and you've >>> instead _silently_ changed the behavior of existing code. One can live with >>> warnings and even errors, but a silent change to existing code is the stuff >>> of nightmares, and I would be strongly opposed to that. >> >> This is a reordering. Banned. End of story. This code is fragile and >> demonstrates a key reason why we need to enforce an ordering invariant. >> >>> >>> >>>> 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. >>> >>> Huh? I use it pervasively. Currently, writing out labels during >>> destructuring guarantees that, even if I've incorrectly memorized the order >>> of the values in a tuple, the tuple is still destructured as I expect. And >>> if reordering were not a feature of Swift, I would still write out these >>> labels. In that case, it would be a static assertion that destructuring is >>> happening in the expected order. That is, if I try to destructure a tuple >>> of type (r: Int, g: Int, b: Int, a: Int) and accidentally write 'let (a: >>> alpha, r: _, g: green, b: _) = ...', I'd get an error and find my mistake >>> at compile time. >>> >>> The whole point of having labels in the first place is clarity at the point >>> of use. Just as SE-0111 will need revision because it removed a key >>> documentation use for argument labels, forbidding labels in tuple patterns >>> would make the same mistake for tuples. >> >> The intent at the time may have been to treat tuples as a kind of >> structurally-typed thing, but shadowing concerns and reordering in patterns >> means this kind of relabeling can be abused and shouldn't be trusted as a >> kind of structural invariant in a pattern - as we seem to agree. To me, >> labels in tuple types provide a means of defining custom projections out of >> the tuple, nothing more. In patterns, I don't see a reason for them. >> >> We can agree that relabeling can be abused, but it does not stand to reason >> that labeling (i.e. the correct, unchanged label) has no role in tuple >> patterns. Again, it serves as documentation for the pattern, just as labels >> serve as documentation for tuples, enum cases, and functions. There are many >> languages that see no reason for labels at all, but Swift is not one of >> those languages. >> >> >>> >>> >>> ~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 https://lists.swift.org/mailman/listinfo/swift-evolution
