🔬 Tracking issue for RFC 2089: Implied bounds

[aturon]

This is a tracking issue for the RFC "Implied bounds" (rust-lang/rfcs#2089).

Steps:

• Implement the RFC (cc @rust-lang/compiler -- can anyone write up mentoring instructions?)
• Adjust documentation (see instructions on forge)
• Stabilization PR (see instructions on forge)

Unresolved questions:

• Should we try to limit the range of implied bounds to be crate-local (or module-local, etc)?
• @nikomatsakis pointed here that implied bounds can interact badly with current inference rules.

[skade]

I have a question not covered in the RFC (that not necessarily has to be part of the RFC): what will error reporting on bounds violations look like? Will it point to the original definition of the bound?

[ExpHP]

I'm not part of this, but I'll summarize what appears to be the current state of this feature from what I can find:

---

This tracking issue was posted shortly before the 2017 impl period began, and it looks like it fell under the scope of the WG-compiler-traits workgroup. On the workgroup's dropbox doc I see (under Query model):

We do have to handle cycles at least as well as chalk for implied bounds to work out

I searched the issue tracker for recent issues/PRs about bound cycles or the query model, but nothing stood out.

[Laaas]

Is this ready for being implemented? And if so, could I get some mentoring instructions?

[scalexm]

Sorry, it seems like this issue has been remaining silent for a long time!
Basically the current state of implied bounds is as follows:

• implied bounds have already been prototyped in chalk, the main work was done in rust-lang-nursery/chalk#82 and another amount of work was done in rust-lang-nursery/chalk#134 where we sketched how implied bounds and generic associated types would interfere
• now the recent effort has been to somehow « connect » rustc and chalk, more info here

We would definitely appreciate contributions for this second point, which may eventually enable really cool features in rustc like implied bounds, generic associated types and more generally better type inference. See you on the Zulip stream!

[scottmcm]

I don't know if this is feasible, but if it is, I think it'd be a nice restriction, so wanted to record it for future consideration:

I think this feature is great for direct uses, but weird for "sideways" uses. To try a concrete example:

// in a world where `struct HashSet<T: Hash+Eq>`...
fn foo<T>(s: &mut HashSet<T>, a: T, b: T) -> bool {
    let r = a == b; // not allowed, because _this_ method doesn't know T: PartialEq
    s.insert(a); // allowed, because the method's `Self` type is HashSet, where we always know Hash+eq
    r
}

I think that would keep the core "look, I'm calling a hashset method, so obviously it's Hash+Eq; I shouldn't need to say so again" but still wouldn't let you directly call things on traits that you never mentioned.

(I do, however, think that in that world, impl<T> HashSet<T> or impl<T> Foo for HashSet<T> should allow use of T:Hash+Eq in the whole impl block, since again it's core to the "self type".)