Unnecessary trait bounds in HashMap (and BTreeMap)

[Rufflewind]

There's a lot of unnecessary trait bounds in HashMap that could be pruned.

Examples:

• impl Default for HashMap<K, V, S> really only needs S: Default
• impl Debug for HashMap<K, V, S> really only needs K: Debug and V: Debug
• Many of the methods only require one out of K: Eq + Hash or S: BuildHasher, or sometimes neither.

Most of this isn't a big deal, but for Default and Debug this is a nuisance because you can't use #[derive(Debug, Default)] on unconstrained types containing HashMap, e.g.

// won't compile
#[derive(Debug, Default)]
struct MyStruct<K>(HashMap<K>);

// your options are to either:
//
//   - needlessly constrain `K` directly on the struct itself,
//     which then infects everything involving MyStruct
//   - define Debug and Default manually with the redundant constraints;
//     downstream types that contain MyStruct are still screwed

One might argue that this would limit potential implementations, but for a lot them like Default or .len(), no sensible implementation should ever use K: Eq + Hash at all.

This also applies to BTreeMap to some extent (Default doesn't need Ord, for example).

Patch: Rufflewind@a1587a1

[bluss]

See also the Implied bounds RFC rust-lang/rfcs/pull/2089 which addresses this, if viewed in a slightly different perspective.

[kennytm]

I believe implied bounds is not going to fix HashMap and BTreeMap, since changing them to require K: Ord in the struct itself will break stability.

[ollie27]

Why doesn't HashMap have K: Eq + Hash and S: BuildHasher on the struct definition itself?