You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A trait definition like this is currently invalid.
traitMode<M>:Mode<A>{typeReturn;}
Instead of being invalid, this should cut the recursion at the point that M == RequiredMode.
Any type that implements Mode<B>must also implement Mode<A> and when selecting specific traits with <T as Trait>, the exact trait should be respected.
<TasMode<B>>::Return// B
<TasMode<A>>::Return// A
<<TasMode<B>> as Mode<A>>::Return// A
As demonstrated in #12511, I would also say that trait T: T {} should be the identity of T, and consequently be the identity of the exception to permit cyclic-safe types.
In theory, there isn't any reason we can't support trait A: B { ... } trait B: A { ... }. We can reason about the cycle the same way we can for trait A: A.
@eefriedman True but that would require understanding the known state, instead of just with the exact trait definition. I think that would require a little more work, but indeed, doable.
Thy cyclic supertrait lint and super-trait tracing code should have an exception to allow for cyclic-safe traits.
https://play.rust-lang.org/?gist=cc794942ed0663d530d8&version=nightly
A trait definition like this is currently invalid.
Instead of being invalid, this should cut the recursion at the point that
M == RequiredMode
.Any type that implements
Mode<B>
must also implementMode<A>
and when selecting specific traits with<T as Trait>
, the exact trait should be respected.As demonstrated in #12511, I would also say that
trait T: T {}
should be the identity ofT
, and consequently be the identity of the exception to permit cyclic-safe types.Cyclic safe traits
Cyclic unsafe traits
The text was updated successfully, but these errors were encountered: