# \[lang-team-minutes\] Implied bounds

**URL:** <https://internals.rust-lang.org/t/lang-team-minutes-implied-bounds/4905>\
**Category:** Uncategorized\
**Created:** [March 3, 2017, 2:18pm UTC](https://internals.rust-lang.org/t/lang-team-minutes-implied-bounds/4905 "2017-03-03T14:18:20Z")\
**Posts on this page:** 1\
**Showing post:** 26

<div class="post-metadata">

**Author:** ![steven099](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/steven099/32/3871_2.png) [@steven099](https://internals.rust-lang.org/u/steven099)\
**Post date:** [March 21, 2017, 6:45pm UTC](https://internals.rust-lang.org/t/lang-team-minutes-implied-bounds/4905/26 "2017-03-21T18:45:22Z")

</div>

> Yes. We're talking about bounds that are required for the receiver to be well formed, I can't possibly have a HashMap to call these methods on without the key being Hash + Eq. What I want is to quickly narrow in on the additional bounds, if any, this impl adds.

Thinking about this, there's an interesting parallel between this discussion and the discussion about [uninhabited types](https://internals.rust-lang.org/t/recent-change-to-make-exhaustiveness-and-uninhabited-types-play-nicer-together/4602). Note that strictly speaking, adding bounds directly on the `HashMap` _type_ would be a breaking change. This code is presently legal:

```rust
use std::collections::HashMap;

fn provide<K, V>() -> HashMap<K, V> {
    unimplemented!()
}

fn consume<K, V>(_: HashMap<K, V>) {}

struct NotHashEq;

fn main() {
    let m = provide::<NotHashEq, i32>();
    consume(m);
    println!("Done");
}

```

Adding the constraint to the `HashMap` type itself would of course make both of these functions ill-formed. Adding implied bounds would make the functions compile, but the calling code would be broken.

You could, recognizing that the basis of adding the implied bounds is the _inhabitedness_ of `HashMap<K, V>`, follow the suggestion by @Fylwind to put the constraint on the `HashMap` _constructor_. This would mean this code would remain legal, you just wouldn't be able to meaningfully implement `provide`, which is exactly the case today due to the public interface of `HashMap`. Then, depending on how Rust ends up reasoning about uninhabitedness, the bounds could be deemed to hold for all uses of the result of `provide`, since either they _do_ hold, or the code is unreachable anyways.

This could of course create surprising results, since someone could design a whole system based around `provide`, and only later realize that `provide` can't be implemented meaningfully. This is somewhat worse than the status quo, since right now, you couldn't do anything _meaningful_ with the result of `provide`, limiting the amount of code that could depend on the (effectively) uninhabited type. The compiler _could_ warn you when the code is invariantly unreachable, e.g. since `HashMap` is known to be _un_inhabited for the provided `K`, rather than simply not being _universally_ inhabited because `K` lacks the appropriate bounds. Note how this relates to above discussion about how the compiler reasons about uninhabited types/variants.

The fact that presently you can't do much with an unbounded `HashMap` is also probably sufficient to make the breaking change of adding the bounds to the type acceptable, since Rust has tended to be pragmatic about this sort of thing. I think it's just worth noting the breakage and the implications of trying to avoid it.

---

_[View the full topic](https://internals.rust-lang.org/t/lang-team-minutes-implied-bounds/4905)._