-
Notifications
You must be signed in to change notification settings - Fork 12.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Can't relate two associated types – unsupported cyclic reference between types/traits #24092
Comments
/cc @nikomatsakis |
Turns out the problem goes away when I use the explicit Aside from the overall problem of it being somewhat inconsistent whether you need to use this syntax or not, this is a deeply misleading error. The fact that it shows up might indicate a problem with how the associated type syntax is seen by the compiler. If not, the error should probably be improved regardless. |
I'm running into this also on |
Hmm, yes. I'm a bit surprised that we wind up with a cycle in that particular example, we may be able to tighten the code to avoid it. |
I came across this too. This errors: use std::ops::*;
trait VectorSpace {}
trait AffineSpace where
Self: Add<Self::Diff, Output = Self>,
Self: Sub<Self, Output = Self::Diff>,
{
type Diff: VectorSpace;
}
Where as this compiles fine: use std::ops::*;
trait VectorSpace {}
trait AffineSpace where
Self: Add<<Self as AffineSpace>::Diff, Output = Self>,
Self: Sub<Self, Output = <Self as AffineSpace>::Diff>,
{
type Diff: VectorSpace;
} |
I have also come across this same issue working on some generic DSP code (I'd post an example of the error however they look very much the same as the examples here by bjz and steveblenkinsop). |
This is basically the same as #35237, closing. |
Trying to compile code with this kind of structure leads to an unsupported cyclic reference error:
This seems somewhat surprising, since,
T
is merely acting as the scope forT::A
andT::B
, which are distinct types. Also, it seems quite reasonable to want to assert a relationship between two associated types. Is there actually something inherently cyclic about this that I'm not seeing, or is it an artefact of how the implementation detects cycles? Also, is this kind of constraint likely to eventually be supported?The text was updated successfully, but these errors were encountered: