On Fri, May 5, 2017 at 12:54 AM, David Hart <da...@hartbit.com> wrote:
> > On 5 May 2017, at 07:17, Robert Widmann via swift-evolution < > swift-evolution@swift.org> 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. > > 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. > > > For what it's worth, I thought I knew Swift inside out and I had never > seen or used the syntax your are proposing to ban, so I'm all for it. > If you google "Swift tuple destructuring," it's demonstrated in the third link you can click on. The article is even titled "best practices": https://github.com/terhechte/appventure-blog/blob/master/resources/posts/2015-07-19-tuples-swift-advanced-usage-best-practices.org ~Robert Widmann > > On May 5, 2017, at 12:53 AM, Xiaodi Wu <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> 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> >> 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> のメッセージ: >>> >>> 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> 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 = 5var y = 10var 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 >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>> >>> > _______________________________________________ > 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