Tuples conform to Equatable

[xwu (Xiaodi Wu)]

@skaller

According to this:

func ff(p:(x:Int,y:Int)) { print(p.x,p.y,p.0,p.1);}
ff (p:(x:1,y:2))
ff (p:(y:2,x:1))
ff (p(1,2))

there's no order for labelled components (that's as close to an equality test as I could do). I have to guess what the types are here. I'm guessing (1,2) converts to (x:1,y:2) to call the function. On the other hand the first two argument are exactly the parameter type. In this case, the conversion in the third call is incoherent, in the sense that, the same argument, if the parameter labels are swapped, will have different semantics even though the parameter type is the same. i must be missing something (because if I'm not the type system is unsound).

In a pre-release version of Swift, arbitrary rearrangement of labeled arguments was supported at call sites. This was removed in favor of a strict order by the time that Swift was released, except for labeled parameters with default arguments. This feature was ultimately removed in SE-0060.

Since tuples and argument lists were the same in prior versions of Swift, this meant that tuples have certain undocumented features required for argument lists, and not all of it has been removed. What you have discovered is an undocumented feature called "tuple shuffling." It has been proposed for removal:

Deprecating Tuple Shuffles (Round 2)

Hello all, @hartbit and I have been thinking a lot about an esoteric feature of Swift called Tuple Shuffles. To that end, we're seeking its removal and believe that we have a proposal ready to do so which I have attached below. Attentive watchers of the Swift Evolution of old will remember that I've raised this idea before. If you want to go see what a really early sketch of this proposal look like, that's over here. Now that we're aiming for a more stable Swift 5, this is as good a time as…

The current state of tuples is summarized as follows:

Single-element labeled tuples?

Right now, Swift's type system allows tuple conversions that both add and remove labels. These kinds of bidirectional subtyping rules are difficult for the type checker because it isn't clear which one is "better" or more specific. If we made the rule directional, to say that maybe (T, U) is a supertype of (label: T, label: U) and not the other way around, then the type checker would be able to clearly favor labeled tuples as more specific than unlabeled ones.

As @rudkx has described, it is a fundamentally broken model:

Single-element labeled tuples?

I've been planning on doing that investigation as part of some implementation work in the type checker. What we have today is just fundamentally broken: let x = (a: 1, b: 2) let z1: (c: Int, d: Int) = x // cannot convert value of type '(a: Int, b: Int)' to specified type '(c: Int, d: Int)' let y: (Int, Int) = x // works: makes sense let z2: (c: Int, d: Int) = y // works: uh, what?

...although it could be possible to fix what's broken without removing tuple shuffling:

Single-element labeled tuples?

Yes I'm aware of some past discussion, and the choice may have been deliberate, but that doesn't mean it's not fundamentally broken. By fundamentally broken I mean that the subtyping relation is transitive, yet you immediately reach a contradiction here: typealias S = (a: Int, b: Int) typealias T = (c: Int, d: Int) typealias U = (Int, Int) var s: S = (a: 1, b: 2) var t: T = (c: 1, d: 2) var u: U = (1, 2) // read X <: Y as X is a subtype of Y u = s // S <: U? yes u = t // T <: U? yes t = s /…

---

As @Slava_Pestov has mentioned, functions used to be modeled as taking a single argument which might be a tuple, and moving away from this model has required a lot of work. Other examples of where Swift's new model isn't fully implemented are as follows:

• Implicit tuple splatting was removed in SE-0029.
• A distinction was made between functions that take a single tuple argument or multiple arguments in SE-0110, but to date this has not been completed implemented, because...
• A "very narrow exception" was required for usability; the plan was to address this more holistically after Swift 4, but that has not yet been done.

---

• Argument labels (unlike tuple element labels) no longer have type system significance due to SE-0111, but...
• This causes a regression for closures that required mitigation, a multi-step plan that has not yet been completed.