Second stabilisation pass of *::num
#20573
Conversation
|
(rust_highfive has picked a reviewer for you, use r? to override) |
|
r? @aturon |
| /// Returns the mantissa, exponent and sign as integers, respectively. | ||
| #[stable] | ||
| fn integer_decode(self) -> (u64, i16, i8); |
There was a problem hiding this comment.
@nagisa on IRC points out that these types are insufficient for e.g. f128, maybe they could become associated types. (Also allows choosing less wasteful ones for f32 compared to f64, but maybe having differing types is just more annoying than its worth.)
There was a problem hiding this comment.
Functions like this are somewhat obscure, and I'd be fine leaving it unstable for now.
|
I would also be fine being much more conservative here and avoid stabilizing more flavorful functions like |
|
Left a few comments. I basically agree with @alexcrichton, although presumably things like re: |
It's actually extra accuracy (e.g. |
|
Ok, I think I've address comments; re-r? |
|
r=me with the tidy failure fixed |
These are replaced by the equivalent constants in `std::f32` and `std::f64` respectively. [breaking-change]
`FloatMath` no longer exists and all functionality from both traits is
available under `Float`. Change from
use std::num::{Float, FloatMath};
to
use std::num::Float;
[breaking-change]
Pending integer conventions.
cc #19260 Open questions: - I still feel weird about marking functions like `exp` as `#[stable]` in `core` since they're highly likely to call into libm which is theoretically something core is designed to avoid and so we may be forced/want to move it at some point in the future, and so it feels like a lie to call it `#[stable]` (I know `core` is `#[experimental]`, but still...) - `abs_sub` is a horrible name IMO: it feels like it is `(a - b).abs()`, but it is actually `(a - b).max(0.)`. maybe something along the lines of `pos_diff` ("positive difference") is better. - the associated-function nature of `Int::from_be` and `Int::from_le` feel strange to me, it feels like they should be methods, but I cannot think of a good name. I'm also not hugely in favour of `ldexp` and `frexp` but the precedent from C is large. (e.g. AFAICT, `ldexp` must mean "load exponent" which is essentially what it does... but only for a subset of its inputs.)
cc #19260
Open questions:
expas#[stable]incoresince they're highly likely to call into libm which is theoretically something core is designed to avoid and so we may be forced/want to move it at some point in the future, and so it feels like a lie to call it#[stable](I knowcoreis#[experimental], but still...)abs_subis a horrible name IMO: it feels like it is(a - b).abs(), but it is actually(a - b).max(0.). maybe something along the lines ofpos_diff("positive difference") is better.Int::from_beandInt::from_lefeel strange to me, it feels like they should be methods, but I cannot think of a good name.I'm also not hugely in favour of
ldexpandfrexpbut the precedent from C is large. (e.g. AFAICT,ldexpmust mean "load exponent" which is essentially what it does... but only for a subset of its inputs.)