-
Notifications
You must be signed in to change notification settings - Fork 13.3k
Defaulted const generic parameters no longer have the const arg's type checked #139643
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
Comments
P-low because it's not going to regress anyone, and its not unsound, and is potentially just a bug fix and is in line with how defaulted generic parameters work in general. cc @rust-lang/types to see if anyone feels strongly about not just accepting this code |
Yeah, we already don't check the well-formedness of default types, so I think not checking the well-formedness of default consts is inevitable here. |
I feel somewhat strongly about it. We currently have the approach of: if the default is fully concrete, check its bounds. I would like to extend this to if the type of the default is fully concrete, check |
We already do that, I think? struct Foo<const N: u32, const M: u64 = "">;
|
No, we check |
check types of const param defaults fixes rust-lang#139643 by checking that the type of a const parameter default matches the type of the parameter as long as both types are fully concrete r? `@BoxyUwU`
…BoxyUwU check types of const param defaults fixes rust-lang#139643 by checking that the type of a const parameter default matches the type of the parameter as long as both types are fully concrete r? `@BoxyUwU`
…xyUwU check types of const param defaults fixes rust-lang#139643 by checking that the type of a const parameter default matches the type of the parameter as long as both types are fully concrete r? `@BoxyUwU`
…BoxyUwU check types of const param defaults fixes rust-lang#139643 by checking that the type of a const parameter default matches the type of the parameter as long as both types are fully concrete r? `@BoxyUwU`
Code
I tried this code:
I expected to see this happen: It fail to compile like it uised to
Instead, this happened: it compile :>
Probably regressed in #125915 where we started lowering const arguments to
ConstArgKind::Path
instead ofConstArgKind::Anon
so there is no longer implicitly an anon const with an expected type ofu64
with an expr typed asu32
.We could probably special case handling of types of defaulted const generics in wfcheck to be done even when generics are involved. Or just accept this as working code which is consistent with things like
struct Foo<T, U = <T as Iterator>::Item>(T, U);
🤷♀ would need a types fcp for that thoI don't believe this to be a soundness bug
The text was updated successfully, but these errors were encountered: