If I understand this correctly, we would still have the following unfortunate situation, and worse:
var a = (x: 12, y: 34) let b = (q: 12, r: 34) print(a == b) // true a = b // ERROR: Cannot assign value of type '(q: Int, r: Int)' // to type '(x: Int, y: Int)'
That is, not only will values of different types continue to compare equal using the equality operator, they will also be equal according to their Equatable protocol conformance.
How can two values be Equatable, Hashable and Comparable when they don't even share the same type (and cannot be assigned to each other or stored in the same Set etc)?
Will this introduce the first and only case in Swift where two values of different types can be equal according to their Equatable conformance?
To make this consistent, some bigger change seems necessary, like deciding that labels are irrelevant for a tuple's type, ie that only the elements decide the type. But I guess this would be a source breaking change, since in current Swift, we have this craziness:
var c = (x: 12, y: 34) let d = (y: 12, x: 34) print(c == d) // true c = d print(c == d) // false
I'd rather see the whole tuple mess cleaned up before building more stuff on top of it.