Change:
<ins> // check-pass use std::ops::Mul; fn main() {} trait Ring {} trait Real: Ring {} trait Module: Sized + Mul<<Self as Module>::Ring, Output = Self> { type Ring: Ring; } trait EuclideanSpace { type Coordinates: Module<Ring = Self::Real>; type Real: Real; } trait Translation<E: EuclideanSpace> { fn to_vector(&self) -> E::Coordinates; fn powf(&self, n: <E::Coordinates as Module>::Ring) -> E::Coordinates { self.to_vector() * n } } </ins>

Discussion:
The trait system seems to be missing a normalization in bounds for associated items: produces the error:
cc
Note that this version works: (Removing the )
, which compiles.
This now compiles.

Gives me: There is a workaround: But it's ugly and should not be necessary. We hit this problem a lot with , and I'd like to see cleaner use of it without explicit bounds that we use as a .
This may be related to .
Edited original post to remove bounds, they're no longer needed. Issue still reproduces:
A lot of related issues for this have been opened over time. Duplicates: , , , , , Probably same underlying cause: , , , , , There's also a related discussion on the Rust forums:
Mildly simplified: So, probably the fix is "just" that we need to do some normalization somewhere or other. My preference is to fix this by moving over to lazy normalization and chalk, which will do away with these sorts of shortcomings for good. But it's probably worth looking to see if this can be fixed a touch more rapidly by adding a normalization in the right place. I'll try to do that in a bit and mentor/open a fix if it seems reasonable.
Any progress here
Looks like the issue is known and mentioned at this line: This indicates this may be the area to check in when working on this? Still working on understanding a lot of this code, so I'm not sure.
Ran into this as well. Here's my minimal test case:
I've just run into this issue in one of my own projects, and reduced it to a test case that's even simpler than the last one: Although it compiles successfully if you add the bizarrely-tautological-looking . For now, I'm stuck with adding the where clause, but that's putting a LOT of boilerplate in my code (the actual where clause is 71 characters long and appears in dozens of places, including being de-facto required in code that uses my library, not just inside the library itself). Is there any progress on this?
: makes the code compile. Edit: updated output: : : Update: this case now compiles. In call cases applying the suggestions fulfill the requirements.
any update on this? Is there anything I can do help with this? I'd be happy and try to help where I can, as this is blocking a lot of nice usages of for me at the moment.
It looks like this compiles under , or at least the bounds compile.

The body function complains about inference, but I'm inclined to think that's just a chalk bug / missing feature and unrelated to this issue. Given that, the solution might just be fully stable chalk integration. If it is, then this issue would fall into the same bucket as features like , where there isn't a lot we can do outside of just pushing chalk integration.
I think my is still correct. I think the normalizing is missing here: After we invoke , we should also be normalizing, probably kind of like this If Chalk solves this, it is probably because of lazy normalization.
All of now compile. I believe this can be closed by adding tests.