On Fri, May 5, 2017 at 12:42 AM, Xiaodi Wu <[email protected]> wrote:
> On Fri, May 5, 2017 at 00:17 Robert Widmann <[email protected]> > 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. > > 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. > > >> >> 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. > I should add, it boggles the mind that you would claim that people will have never heard of this before today. It's been discussed _on this very list_!
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
