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.zuba...@devandartist.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
