-
Notifications
You must be signed in to change notification settings - Fork 205
Open
Description
Hey this is a bit of an ergonomic issue, to_f64
returns an option, but it's actually infallible.
I can see this is a bit of a legacy wart of the api:
fn to_f64(&self) -> Option<f64> {
if self.scale() == 0 {
let integer = self.to_i64();
match integer {
Some(i) => Some(i as f64),
None => None,
}
} else {
// TODO: Utilize mantissa algorithm.
match self.to_string().parse::<f64>() {
Ok(s) => Some(s),
Err(_) => None,
}
}
}
Way back in 2020 it was optional, but no longer.
This is one of those things that causes me to double take EVERY time I do an unwrap: I'll check if there are actually any error cases to reassure myself that my unwrap isn't going to cause a really stupid panic in serialisation code.
Now it handles all possible paths I believe it's worth having an alternative function like as_f64
. I gave some thought about the function name and 'as' makes the most amount of sense to me. I thought about unchecked
or trusted
those imply unsafeness or fallibility.
jstrong-lhava
Metadata
Metadata
Assignees
Labels
No labels