[swift-evolution] [Proposal][Discussion] Deprecate Tuple Shuffles

Fri May 5 10:17:52 CDT 2017

```
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 at 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.videla at 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 at 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 (david at 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.zubarev at 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 at swift.org) schrieb:
>>
>>
>>
>> On 5 May 2017, at 10:59, Xiaodi Wu via swift-evolution <
>> swift-evolution at swift.org> wrote:
>>
>> 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
>>>
>>
>> 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 at swift.org> wrote:
>>>
>>> On Fri, May 5, 2017 at 2:28 AM, Adrian Zubarev <adrian.zubarev at 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 at swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>
>>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170505/340a82d4/attachment.html>