Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.
Sign upNumeric fallbacks don't work when inherent methods are involved #24124
Comments
XMPPwocky
referenced this issue
Apr 6, 2015
Closed
Numeric fallbacks don't work when inherent methods are involved #24123
This comment has been minimized.
This comment has been minimized.
azar77
commented
Apr 7, 2015
|
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 |
steveklabnik
added
the
A-typesystem
label
Apr 7, 2015
This comment has been minimized.
This comment has been minimized.
|
Moreover, the language reference says that
So, if the reference was respected, it would default to |
IvanUkhov
referenced this issue
Jul 21, 2016
Closed
Do not suggest internal crates in error messages #34950
This comment has been minimized.
This comment has been minimized.
CasualX
commented
Jul 20, 2017
|
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 |
Mark-Simulacrum
added
C-bug
A-inference
labels
Jul 22, 2017
This comment has been minimized.
This comment has been minimized.
|
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 |
XMPPwocky commentedApr 6, 2015
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.