Add Index impls for IdHashMap and IdOrdMap - #310
Open
ChrisJr404 wants to merge 1 commit into
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Hello! This picks up #9, adding
Indeximpls forIdHashMapandIdOrdMapso you can look an item up withmap[&key], the waystd'sHashMapandBTreeMaplet you. Like those, indexing panics when the key is absent, andgetis still there for the non-panicking version.You mentioned trouble lining up the lifetimes, and I ran into the same wall at first. The issue is that
get's query bound ties the key lifetime to the borrow ofself, butIndex::indexdoesn't let you name that borrow in the impl. Making the bound higher-ranked over the key lifetime (for<'k> Equivalent<T::Key<'k>>, and theComparableequivalent for the ord map) gets it to compile and still covers the normal cases, like&strkeys queried withstr. There's a test for that borrowed-key case on both maps so it doesn't silently regress.I kept this to the two single-key maps that the issue asks about.
BiHashMap/TriHashMaphave more than one key, soIndexthere is a bit more of a design question and I left it out.Added tests and doc examples for both, plus a CHANGELOG entry.