Change:
help: if `Iterator::Item` is an associated type you're trying to set, use the associated type binding syntax | LL - fn sum<I: Iterator<Item = ()>>(i: I) -> i32 where I::Item = i32 { <del> LL + fn sum<I: Iterator<Item = (), Item = i32>>(i: I) -> i32 where  { </del> <ins> LL + fn sum<I: Iterator<Item = (), Item = i32>>(i: I) -> i32  { </ins> | error: equality constraints are not yet supported in `where` clauses

Discussion:
partially addresses , but we need to resugar the predicates to unify the output of a trait obligation with related projection obligations (associated types). For example should be
I hit this today, couldn't remember the exact prototype so I wanted the compiler to suggest it to me (typing this, I realize how amazing it is that Rust gets most of these suggestions right. Thanks for all the work in this area!). Playground: Copy-pasting the suggestion leads to this: About the second error: Couldn't the compiler also deduce that is in fact here? I couldn't find an open issue specific to this. For the resugaring error, I'd be willing to tackle this, if you think this is something achievable for a contributor!
there are different parts that could potentially be tackled of different level of difficulty. The underlying problem is that by the time the compile error happens, we no longer have access to the original bound information. We know that the method requires to be , and that , but we no longer have the metadata that ties those two bounds together, as far as is concerned, they are two different things, which is why the output looks the way it does. Extending the metadata to keep those two things mergeable at that stage is probably a medium sized undertaking requiring to touch a fair amount of the compiler. I would advice against trying that as a newcomer An alternative to the "correct" fix above would be to try to unify multiple bounds into a single one when possible. Doing that is concentrated in a single part of the compiler, which can be easier to understand, but will require tricky logic. I would look at all the traits bounds (s in parlance) and see if an associated type equality constraint has a self type mentioned in a trait bound on the RHS of the bound. Meaning, if you have , look for in all bounds. If found, you have to figure out how to "print" it. There might be some existing code that can be reused to make this as resilient as any other part, potentially building a with all the necessary parts, but I'd be happy enough with "one off" for this use case with a comment. Finally, I would love to handle the equality constraint case in a more user friendly way, similar to : we should detect that this is constraining an associated type and provide the same suggestion as in the previously mentioned case.

If that is too hard to do, we could at least mention_ what the solution is given is an associated type in a (not a structured suggestion). What do you think? Is any of this something of the scope size you'd like to tackle? Edit: Looking at , it seems to me like what would be necessary to accomplish the last part of my comments above would be to and perform the "unification" I mentioned for the previous cases, so doing either the first or second approach, you can get the last case almost for free
Hi sorry for the late reply. I think I can try and build something for the alternative to the "correct" fix you mention, i.e. manually merge an associated type equality constraint bound with another bound if the other bound is about as well. Making sure I understand this correctly, the difference with the previous idea would be correcting the user when he writes the equality constraint, rather fixing the suggestion provided by the compiler? (both things being complementary to each other, of course). Did I get this right? :smile: So starting with this seems like it'd be a good path? If I understand correctly, implementing the "manual merge" of related bounds would allow its use both to fix the "method impl" suggestion I hit with above, as well as add a new helpful suggestion when the user writes an equality constraint?
I'll start working on that "unification". Looking at , I'm having a hard time identifying where I'd get started though :sweatsmile: , , ...
friendly ping in case this went past you (nothing pressing if you're not available though!)
I think you got it right, we would want to support both cases independently (likely in separate PRs). One is reducing the likelihood of hitting the equality case, but anyone could try to write it without waiting for rustc to point them in that direction, so ideally we cover both cases. Correct. It would be what we need and would work for most cases (but not 100% because we're rejoining things that got separated for a reason, but it would work well enough for all the common cases). Now with a fresh set of eyes I'm thinking now that you can probably try to unify things just with the information you have in and by looking at the and try to "merge" the ones that are related. Sorry!

The previous notifications did indeed get drowned and am currently with intermittent internet access. Do not hesitate to ping me again if you need any further help though!
Current output: We need to fix how we handle the incorrect syntax, but the initial suggestion is now fixed.