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.

Sign up for GitHub

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

Jump to bottom

std::collections::hash_map::{Entry, OccupiedEntry, VacantEntry} are never Send/Sync #45219

Closed
sdleffler opened this issue Oct 11, 2017 · 2 comments · Fixed by #58369
Closed

std::collections::hash_map::{Entry, OccupiedEntry, VacantEntry} are never Send/Sync #45219

sdleffler opened this issue Oct 11, 2017 · 2 comments · Fixed by #58369
Labels
C-feature-accepted Category: A feature request that has been accepted pending implementation. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.

Comments

@sdleffler
Copy link
Contributor

Currently, the HashMap entry types are never Send or Sync. It seems to me that the Entry types should be Send whenever their key/value types are Send and Sync whenever their key/value types are Sync. Properly implementing Send/Sync for OccupiedEntry and VacantEntry will solve the problem for Entry as well. Is there any known reason why Entry and friends should not be Send or Sync?
@cuviper
Copy link
Member

cuviper commented Oct 12, 2017

For comparison, btree_map::Entry has both Send and Sync -- manually implemented on NodeRef and then automatically propagating up. The similar low level for HashMap would be the RawBucket.

@TimNN TimNN added C-feature-request Category: A feature request, i.e: not implemented / a PR. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. labels Oct 17, 2017
@dtolnay dtolnay added C-feature-accepted Category: A feature request that has been accepted pending implementation. and removed C-feature-request Category: A feature request, i.e: not implemented / a PR. labels Nov 14, 2017
@nox
Copy link
Contributor

nox commented Feb 10, 2019

It's not clear to me whether propagating from RawBucket is a good idea, given that if the Send impl of hash_map::Iter is removed, hash_map::Iter would then implement Send where K: Send, V: Send instead of K: Sync, V: Sync.

@nox nox mentioned this issue Feb 11, 2019
Merged
nox added a commit to nox/rust that referenced this issue Mar 4, 2019
@nox
Make the Entry API of HashMap<K, V> Sync and Send (fixes rust-lang#45219
1fec8c2 
)
pietroalbini added a commit to pietroalbini/rust that referenced this issue Mar 8, 2019
@pietroalbini
Rollup merge of rust-lang#58369 - nox:sync-hash-map-entry, r=Amanieu
55dc386 
Make the Entry API of HashMap<K, V> Sync and Send

Fixes rust-lang#45219
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
C-feature-accepted Category: A feature request that has been accepted pending implementation. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Make the Entry API of HashMap<K, V> Sync and Send nox/rust
5 participants
@cuviper @nox @TimNN @dtolnay @sdleffler