The situation is weird because tuples of the same element types but different labels are currently equal (by
==) but their types are not equal (by
Also, tuples with different labels but the same element types cannot be assigned to one another, unless one of the two has no labels.
Which means transitively, by going through a temporary with no labels, tuples with different labels can be assigned to each other, there’s just an extra step involved.
• • •
• The proposed solution ignores tuple labels and just compares elements, which matches the behavior of the existing hard-coded
== operators for tuples.
• An alternative could respect tuple labels, meaning if the labels don’t match then the
Equatable conformance does not apply (because the types are different), but it would still be possible to use the existing hard-coded
== operators for those tuples.
• We could declare that tuple labels always matter (except possibly when one side has no labels), which would involve the source-breaking change of removing the existing
== comparison operators for tuples. This is probably a non-starter for source-compatibility reasons.
• We could declare that tuple labels never matter (except for enabling convenience accessors), which would make tuples purely structural. In that world, any time that labels matter would be a job for
The last option is conceptually the simplest, and it is similar to what was done for function types in SE–0111: Remove type system significance of function argument labels.