[swift-evolution] [Proposal][Discussion] Deprecate Tuple Shuffles
xiaodi.wu at gmail.com
Fri May 5 03:59:51 CDT 2017
On Fri, May 5, 2017 at 03:11 André Videla <andre.videla at gmail.com> wrote:
> Just to make sure:
> let pair = (x: 3, y: 5)
> Let swapped: (y: Int, x: Int) = pair
Let (y: x1, x: y1) = pair
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 at swift.org> wrote:
> On Fri, May 5, 2017 at 2:28 AM, Adrian Zubarev <
> adrian.zubarev at 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:
>> 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 at swift.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution