Closed vanvoorden closed 3 months ago
Generally, it's good practice for Equatable types to also conform to Hashable
https://developer.apple.com/documentation/swift/dictionary/keys-swift.struct#conforms-to
@lorentey Hmm… it looks like Swift.Dictionary.Keys
actually does not conform to Hashable (but does conform to Equatable). There might be some interesting use cases enabled when an engineer can assume TreeDictionary.Keys
was Hashable… but it looks like the precedent from the Standard Library Dictionary
is that just Equatable might be good enough for now.
Unfortunately the Standard Library does not set a good example here, as we cannot easily add missing conformances there that we forgot to ship in the initial release. (They are potentially ABI breaking.)
we cannot easily add missing conformances there that we forgot to ship in the initial release
@lorentey Hmm… something like what we do for TreeSet
might work here? Want me to give it a try and post a diff?
Yes, that's precisely the pattern! 👍
Yes, that's precisely the pattern!
@lorentey Sounds good. I can try that. Would it be ok to add a new commit here to this diff for another review to save us the merge conflict from trying to land both?
For sure! Adding a commit here is best.
@swift-ci test linux platform
Background
Unlike
Swift.Dictionary.Keys
^1,TreeDictionary.Keys
does not currently conform toEquatable
. Achieving more parity with the standard library dictionary could lower friction for more engineers to migrate toTreeDictionary
in their own repos.Changes
We can copy the approach from
TreeSet
:Since we don't care if values are equal (only the keys), we can hardcode the equality closure to always return
true
.Similar to our equality check on
TreeDictionary
, we expect to returntrue
in constant-time if two values are identical by reference (no need for a linear-time check).Test Plan
We add
TreeDictionaryKeysTests.test_isEqual_exhaustive
. We can expand on these tests if necessary.Benchmarks
Checklist