Skip to content

HashMap, HashSet: impl Hash #48366

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

Closed
wants to merge 4 commits into from
Closed
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
32 changes: 32 additions & 0 deletions src/libstd/collections/hash/map.rs
Original file line number Diff line number Diff line change
Expand Up @@ -1370,6 +1370,38 @@ impl<K, V, S> Eq for HashMap<K, V, S>
{
}

#[unstable(feature = "hashmap_hash", issue = "0")]
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

impls are insta-stable

impl<K, V, S> Hash for HashMap<K, V, S>
where K: Eq + Hash,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is the Eq bound necessary here?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, it is necessary for self.iter() - you can't call that otherwise. You could use self.table.iter() which would not require Eq. So self.iter() could be changed to not require Eq. But I think it is right to require K: Eq since you shouldn't be able to do anything useful with a HashMap<K, V, S> unless K: Eq.

V: Hash,
S: BuildHasher
{
fn hash<H: Hasher>(&self, hasher: &mut H) {
// We must preserve: x == y -> hash(x) == hash(y).
// HashMaps have no order, so we must combine the elements with an
// associative and commutative operation • so that the order does not
// matter. In other words, (u64, •, 0) must form a commutative monoid.
// This is satisfied by • = u64::wrapping_add.
//
// We must further ensure that the hashing of individual elements does
// not depend on the state of the given Hasher. So we ensure that
// hashing each individual element starts with the same state.
//
// Unfortunately, we can't .clone() the hasher since we can't add more
// constraints than H being a Hasher. With some sort of ConstraintKinds
// we might be able do so in the future.
hasher.write_u64(
self.iter()
.map(|kv| {
let mut h = DefaultHasher::new();
kv.hash(&mut h);
h.finish()
})
.fold(0, u64::wrapping_add)
);
}
}

#[stable(feature = "rust1", since = "1.0.0")]
impl<K, V, S> Debug for HashMap<K, V, S>
where K: Eq + Hash + Debug,
Expand Down
12 changes: 11 additions & 1 deletion src/libstd/collections/hash/set.rs
Original file line number Diff line number Diff line change
Expand Up @@ -10,7 +10,7 @@

use borrow::Borrow;
use fmt;
use hash::{Hash, BuildHasher};
use hash::{Hash, Hasher, BuildHasher};
use iter::{Chain, FromIterator, FusedIterator};
use ops::{BitOr, BitAnd, BitXor, Sub};

Expand Down Expand Up @@ -757,6 +757,16 @@ impl<T, S> Eq for HashSet<T, S>
{
}

#[unstable(feature = "hashmap_hash", issue = "0")]
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

impls are insta-stable

Copy link
Contributor Author

@Centril Centril Feb 20, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hmm yes, true... maybe it should be #[stable(feature = "hashmap_hash", since = "1.26.0")]?

impl<T, S> Hash for HashSet<T, S>
where T: Eq + Hash,
S: BuildHasher
{
fn hash<H: Hasher>(&self, hasher: &mut H) {
self.map.hash(hasher);
}
}

#[stable(feature = "rust1", since = "1.0.0")]
impl<T, S> fmt::Debug for HashSet<T, S>
where T: Eq + Hash + fmt::Debug,
Expand Down