The Core Team today discussed this proposal and how we'd like to manage review of this and related functionality. We agree that the lack of these conformances is a significant pain point in the language and that it's worth considering introducing special case behavior until more general mechanisms for extending structural types are available. As far as structuring the review discussion goes:
- We think that there is a core set of protocol conformances that clearly make sense for tuples, and have an obvious implementation that the standard library would provide if the language today allowed for it:
Equatable,Hashable, andComparable. The core team would like to see a single proposal covering these conformances. - We also think that tuples should clearly conform to
Codable. However, there are enough implementation details to discuss about how tuples ought to be coded that the core team would like to see some discussion of this aspect. If there is a lot of contention about these details, tupleCodableconformance may deserve its own proposal and review. - Other categories of structural types also have obvious conformances, such as metatypes being
Hashableand existentials beingHashablewhen their protocol constraints implyHashable, and these deserve separate proposals as viable implementations become available.
In the ensuing discussion, we'd like to see attention paid to the long-term compatibility tradeoff of special-casing these conformances today, vs. what future language directions such as variadic generics may enable. If we accept any of these proposals, we would be committing to preserving compatibility with the source-level behavior, and on ABI-stable platforms, any runtime behavior and ABI requirements this introduces, even when more general mechanisms get introduced in the future. It would be good to explore and enumerate what these long-term liabilities are so that we know what we would be committing to.