Currently most impl blocks over types in dashmap use similar trait bounds (e.g., K: Eq + Hash) even when those traits aren't actually "used" in the implementations. This forces users writing generic code over dashmap objects to include the same restrictions in their impl blocks.

By contrast, most standard library crates use the least restrictive bounds possible for each method, even if it's not clear why anyone would want to use those methods without common-sense trait bounds. For example, see the trait bounds on IntoIterator for hashbrown::HashMap vs. IntoIterator for DashMap, which requires K: Eq + Hash even though the implementation does not truly depend on those constraints.

In the worst case, this prevents users from deriving traits like Debug on generic types containing DashMaps. This example of a wrapper struct compiles for hashbrown::HashMap, but fails when it instead tries to wrap DashMap because K is not constrained by Eq + Hash. The implementation of Debug on DashMap doesn't ultimately use the Eq or Hash implementations on K (although some of the intermediate types it uses also have the spurious bounds), so this issue could be avoided by removing the trait bounds.

If you're interested in fixing this issue, I'd be happy to send a PR or a few to address some of the most limiting spurious bounds.