KeyValuePairs conditional conformance to Equatable / Hashable

Evolution Pitches
1

Is there a reason that KeyValuePairs doesn't conditionally conform to Equatable and / or Hashable? i.e. :

extension KeyValuePairs: Equatable where Key: Equatable, Value: Equatable { /* ... */ }
extension KeyValuePairs: Hashable where Key: Hashable, Value: Hashable { /* ... */ }

I see that in the original proposal that introduced conditional conformances (#0143), the types that would adopt conditional conformances were explicitly enumerated and were therefore subject to community review. Would it require an Evolution Proposal with a review cycle to add a conditional conformance to a Standard Library type like KeyValuePairs?

3 Likes
2

At the time, IIRC, the type was still called DictionaryLiteral and essentially pigeonholed into one purpose so that might have been why it it was overlooked in that proposal.

I can’t think of any reason why it shouldn’t have those conformances*, now that is established in the stdlib for general use.

*(the type wraps an array of tuples, so actually implementing the conformances will be a bit annoying as you won’t get to take advantage of auto-synthesis, but obv. that can be dealt with)

3

In the short term, adding the conformances would require a way of handling conformance availability (or one of the other solutions from Backwards-deployable Conformances). In the long term I agree it seems like a sensible addition though.

3 Likes
4

Oh yeah, that is an obstacle.