``` 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" ``` ^^I would like for this not to be possible. That is not at all what I expect or–even now that I see what is happening–desire in any way. TJ On Fri, May 5, 2017 at 8:28 AM, Adrian Zubarev via swift-evolution < swift-evolution@swift.org> wrote: > To solve the issues with the destructuring I’d suggest to make the labels > fully optional, so extracting inner tuples wouldn’t be a pain in the ass as > it is right now. > > let tuple = (value: 0, point: (x: 0, y: 0, z: 0)) > > let (value, point: (x, y, z)) = tuple > > Alternatively one could remove labels completely and let the compiler > provide a suggestion for name of each value of the tuple destructuring, or > you could your own names, while inner path would have some function-like > syntax instead of confusing labels. > > let (value, point(x, y, z)) = tuple > > The latter would mean that tuple destructuring would always remove the > labels from rhs tuple. > > In the example from above we’d get a change from: > > (value: Int, point: (x: Int, y: Int, z:Int)) to (Int, (Int, Int, Int)). > > > > -- > Adrian Zubarev > Sent with Airmail > > Am 5. Mai 2017 um 14:07:11, André Videla (andre.vid...@gmail.com) schrieb: > > It really strikes me as an inconsistency in the type system. The type > system already enforces order in other labeled expression like function > calls > > func takePair(x: Int, y: Int) { } > > takePair(y: 5, x: 5) // error > > func takePair(y: Int, x: Int) { } > > takePair(y: 5, x: 5) // ok, dispatches to the second function because > it's the only one that type checks with labels > > or enums > > enum Pair { > > case point(x: Int, y: Int) > > } > > let p: Pair = .point(y: 3, x: 4) // error > > Even if those features are semantically different and have nothing to do > with the deconstruction of tuples they still suggest that labeling order is > important. And teaches the programmer to expect that the order of labels is > enforced. > > If you assume that label order is important why would you expect this to > typecheck? > > let (y: a, x: b) = (x: 1, y: 2) > > let pair: (y: Int, x: Int) = (x: 1, y: 2) > > 2017-05-05 13:29 GMT+02:00 Adrian Zubarev via swift-evolution < > swift-evolution@swift.org>: > >> I’m confused here. You’re referring to this example: >> >> let pair = (x: 3, y: 5) >> let swapped: (y: Int, x: Int) = pair >> >> In this case you’re shuffling/swapping the labels of the type from: >> >> (x: Int, y: Int) to (y: Int, x: Int), which from my understanding of the >> whole pitch should be an error. The tuple types may look similar, but >> because the labels have a totally different order, I’d assume the types are >> different even if they share the same labels and types. >> >> >> -- >> Adrian Zubarev >> Sent with Airmail >> >> Am 5. Mai 2017 um 13:12:31, David Hart (da...@hartbit.com) schrieb: >> >> But we’re not reordering labels, we’re assigning to a different variable >> which has different variable names. And I think it should work because we >> are not using the restructuring syntax. >> >> On 5 May 2017, at 12:11, Adrian Zubarev <adrian.zuba...@devandartist.com> >> wrote: >> >> I would assume the error is correct, because if we ban reordering than >> labeled tuple types will become incompatible if the labels are swapped, >> remember the strict order or labels. >> >> >> >> -- >> Adrian Zubarev >> Sent with Airmail >> >> Am 5. Mai 2017 um 12:08:59, David Hart via swift-evolution ( >> swift-evolution@swift.org) schrieb: >> >> >> >> On 5 May 2017, at 10:59, Xiaodi Wu via swift-evolution < >> swift-evolution@swift.org> wrote: >> >> On Fri, May 5, 2017 at 03:11 André Videla <andre.vid...@gmail.com> wrote: >> >>> >>> Just to make sure: >>> >>> let pair = (x: 3, y: 5) >>> Let swapped: (y: Int, x: Int) = pair >>> >> >> Error. >> >> >> Why error here? In this case. It's not a label but he type. >> >> Let (y: x1, x: y1) = pair >>> >> >> Error. >> >> Let (x: x2, y: y2) = pair >>> >> >> With the revised pitch that no longer prohibits all labels, x2 is 3 and >> y2 is 5. In the original version, error. >> >> Let (x3, y3) = pair >>> >> >> x3 is 3 and y3 is 5. >> >> After the change, What do (x_n, y_n) print and Which assignments are >>> errors? >>> >>> Andre Videla >>> >>> On 5 May 2017, at 09:31, Xiaodi Wu via swift-evolution < >>> swift-evolution@swift.org> wrote: >>> >>> On Fri, May 5, 2017 at 2:28 AM, Adrian Zubarev <adrian.zubarev@devand >>> artist.com> wrote: >>> >>>> I’m not arguing to remove all labels in Swift. Labels are great, this >>>> is a fact for sure. The point I was trying to make is that labels in tuples >>>> how either a meaning or not at all. >>>> >>>> // This is a shortcut for the tuple type `(x: Int, y: Int)` >>>> let foo = (x: 0, y: 0) >>>> >>>> // In this case the labels are only used for description, >>>> // they do not server any benefit here are most likely redundant >>>> let (x: x, y: y) = foo >>>> >>>> Labels elsewhere are a different story and I do support the cosmetic >>>> addition Chris Lattner sketched out here: https://lists.swift.org/ >>>> pipermail/swift-evolution-announce/2016-July/000233.html >>>> >>>> However this is about closures and not tuples, I don’t think this would >>>> anyhow affect the removal of labels in tuple destructuring. >>>> >>>> Plus I don’t see this to create an inconsistent in Swift, because as I >>>> already said, labels in tuple destructuring are useless. >>>> >>> How come? I just illustrated their use. They help humans write correct >>> code by allowing the compiler to check an assertion that the human knows >>> which labels go with which positions in the tuple. >>> >>> _______________________________________________ >>> >>> >>> 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 >> >> >> >> _______________________________________________ >> 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