I was attempting to solve this very problem in the Rust BigDecimal crate this weekend. Is it better to just let it crash with an out of memory error, or have a compile-time constant limit (I was thinking ~8 billion digits) and panic if any operation would exceed that limit with a more specific error-message (does that mean it's no longer arbitrary-precision?). Or keep some kind of overflow-state/nan, but then the complexity is shifted into checking for NaNs, which I've been trying to avoid.
Sounds like Haskell made the right call: put warnings in the docs and steer the user in the right direction. Keeps implementation simple and users in control.
To the point of the article, serde_json support is improving in the next version of BigDecimal, so you'll be able to decorate your BigDecimal fields and it'll parse numeric fields from the JSON source, rather than json -> f64 -> BigDecimal.
#[derive(Serialize, Deserialize)]
pub struct MyStruct {
#[serde(with = "bigdecimal::serde::json_num")]
value: BigDecimal,
}
Whether or not this is a good idea is debatable[^], but it's certainly something people have been asking for.
[^] Is every part of your system, or your users' systems, going to parse with full precision?
Sounds like Haskell made the right call: put warnings in the docs and steer the user in the right direction. Keeps implementation simple and users in control.
To the point of the article, serde_json support is improving in the next version of BigDecimal, so you'll be able to decorate your BigDecimal fields and it'll parse numeric fields from the JSON source, rather than json -> f64 -> BigDecimal.
Whether or not this is a good idea is debatable[^], but it's certainly something people have been asking for.[^] Is every part of your system, or your users' systems, going to parse with full precision?