-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
fix std::f32 and std::f64 constants #13710
Conversation
The old implementation of |
@sfackler right -- note that I left |
Thanks, @aturon. |
Some of the constant values in std::f32 were incorrectly copied from std::f64. More broadly, both modules defined their constants redundantly in two places, which is what led to the bug. Moreover, the specs for some of the constants were incorrent, even when the values were correct. Closes rust-lang#13297. Closes rust-lang#11537.
r? |
@@ -64,26 +64,23 @@ mod cmath { | |||
} | |||
} | |||
|
|||
// FIXME(#11621): These constants should be deprecated once CTFE is implemented | |||
// in favour of calling their respective functions in `Bounded` and `Float`. | |||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why was this comment removed? It should probably be changed to being dependent on associated items rather than CTFE, but I think a mention is important.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks; I'll make that change.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@bjz is there an issue or RFC for associated items? I couldn't find one via github's search. If not, perhaps best to leave as a reference to CTFE for now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
#5527 maybe?
Agreed about the min and max value names being misleading. The |
Some of the constant values in std::f32 were incorrectly copied from std::f64. More broadly, both modules defined their constants redundantly in two places, which is what led to the bug. Moreover, the specs for some of the constants were incorrect, even when the values were correct. Closes #13297. Closes #11537.
Follow-up on issue rust-lang#13297 and PR rust-lang#13710. Instead of following the (confusing) C/C++ approach of using `MIN_VALUE` for the smallest *positive* number, we introduce `MIN_POS_VALUE` (and in the Float trait, `min_pos_value`) to represent this number. This patch also removes a few remaining redundantly-defined constants that were missed last time around.
Follow-up on issue #13297 and PR #13710. Instead of following the (confusing) C/C++ approach of using `MIN_VALUE` for the smallest *positive* number, we introduce `MIN_POS_VALUE` (and in the Float trait, `min_pos_value`) to represent this number. This patch also removes a few remaining redundantly-defined constants that were missed last time around.
Some of the constant values in std::f32 were incorrectly copied from
std::f64. More broadly, both modules defined their constants redundantly
in two places, which is what led to the bug. Moreover, the specs for
some of the constants were incorrect, even when the values were correct.
Closes #13297. Closes #11537.