-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
Recursive generic type parameters can give confusing error messages #53191
Comments
I'm brand new to rust and ran into this while trying to reproduce another issue. I actually don't understand why this is silly or why the error applies. Without seeing this, I generated exactly the same code except my struct was called use std::marker::PhantomData;
struct A<T> {
x: Option<Box<A<T>>>,
_z: PhantomData<T>,
}
fn main() {
let a = A::<i32> {
x: None,
_z: PhantomData
};
assert!(a.x.is_none());
} |
If you need recursive generic type parameters without |
I am usually an advocate for experimenting with nightly features, even "in production", but that is contingent on the fact that most nightly features are actually quite sound. I strongly advise against using an incomplete feature for any practical code of significant use. |
Rollup merge of rust-lang#127871 - compiler-errors:recursive, r=estebank Mention that type parameters are used recursively on bivariance error Right now when a type parameter is used recursively, even with indirection (so it has a finite size) we say that the type parameter is unused: ``` struct B<T>(Box<B<T>>); ``` This is confusing, because the type parameter is *used*, it just doesn't have its variance constrained. This PR tweaks that message to mention that it must be used *non-recursively*. Not sure if we should actually mention "variance" here, but also I'd somewhat prefer we don't keep the power users in the dark w.r.t the real underlying issue, which is that the variance isn't constrained. That technical detail is reserved for a note, though. cc `@fee1-dead` Fixes rust-lang#118976 Fixes rust-lang#26283 Fixes rust-lang#53191 Fixes rust-lang#105740 Fixes rust-lang#110466
If I have code like this:
I get the following compiler error message:
The error message is, IMHO, technically correct, but not necessarily helpful. Now, in this particular example, it's relatively obvious what the mistake is, but I stumbled across it while doing a refactoring that tweaked a complex
enum
-- I was baffled for a while :) My intuitive explanation is that although I'm "using"T
by passing it recursively toS
I'm never "consuming"T
by attaching it to a concrete type.I wonder if E0392 might want to be special cased / reworded to cover this particular case? I appreciate it's not a common one, but I'm probably not the first person to do something silly like this.
The text was updated successfully, but these errors were encountered: