-
Notifications
You must be signed in to change notification settings - Fork 13.2k
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
Numeric fallbacks don't work when inherent methods are involved #24124
Comments
I encountered a similar problem: fn sqrt2() -> f64 {
let x = 2.0;
x.sqrt()
}
fn two_plus_three() -> u64 {
let x = 2;
x.checked_add(3).unwrap()
} In both cases, the compiler fails to infer the type of |
Moreover, the language reference says that
So, if the reference was respected, it would default to |
I just ran into this writing some example codes (where it's more likely to have a lot of 'unconstrained' hard coded constants), note the very unhelpful error message:
https://play.rust-lang.org/?gist=24e7667d5a1ea0c7b8702e9ac4a075b4&version=stable |
This was also reported as a pain point in the "Ideas for making Rust easier for beginners" internals thread: https://internals.rust-lang.org/t/ideas-for-making-rust-easier-for-beginners/4761/37 |
Readers of our book 'Programming Rust' have reported errata related to this, because it's hard to explain that operators and trait methods work on unresolved |
The current error is much clearer, but this ticket is still valid because it is about inference itself:
|
Weirdly enough, this does work for trait methods (playground): trait Foo {
fn foo(&self);
}
impl Foo for i16 {
fn foo(&self) {
println!("i16");
}
}
// Uncomment to change the output in `main`
//
// impl Foo for i32 {
// fn foo(&self) {
// println!("i32");
// }
// }
fn main() {
3.foo();
} So it definitely seems like it should be possible. |
I would expect
2.0.sqrt()
to return sqrt(2) as a f64. Instead,... and the Float trait is deprecated!
This also occurs with integer literals.
I ran into this in the wild while doing an exponential decay:
A workaround is to annotate the literal's type explicitly.
The text was updated successfully, but these errors were encountered: