Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement the whole HashMap interface #13

Open
1 of 27 tasks
hmuendel opened this issue Apr 19, 2020 · 3 comments
Open
1 of 27 tasks

Implement the whole HashMap interface #13

hmuendel opened this issue Apr 19, 2020 · 3 comments

Comments

@hmuendel
Copy link
Contributor

hmuendel commented Apr 19, 2020

First of all, thank you very much for the quick responses and gentle guidance. I also stumbled over the missing len() method, which I implemented for myself in my fork. A lot of these methods are very easy to pass through from the underlying HashMap. Here is a list of all methods missing compared with HashMap.

Methods

Trait Implementations

Blanket Implementations

If you have no objections, I would try to implement some of the these, in the coming weeks and create PRs as soon as I accumulated a meaningful contribution. If someone else is working on it, we could check the boxes, to avoid duplicate work

@jeff-hiner
Copy link
Contributor

I just bumped into not having clear() which was a little disappointing (though I was able to work around it with mem::replace).

Rather than tackling all of these, maybe it's best to attempt the low-hanging fruit first? I'd probably avoid naively implementing with_hasher because you may want to use different hashers for each underlying HashMap, but things like values_mut should be relatively straightforward. I'd like to PR some of these in, if this project is still maintained.

@eldruin
Copy link
Member

eldruin commented Jan 30, 2021

That sounds good to me @jeff-hiner :)

@JustForFun88
Copy link

JustForFun88 commented Mar 20, 2022

I implement almost whole list of requests, but there are some difficulties with naming of functions.

It is very difficult to remember that methods with "alt" it is methods with key 2, and without "alt" it's methods with key 1.
And also these all methods names have different length, mismatched and not symmetrical.

Can we change the existing API? Renaming methods with suffix "key1", "key2" or "keys"?
For example with changing the version of crate to 2.0.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants