Arnavion
commented
1 year ago Ref:
Perhaps adding various methods similar to its Go counterpart.
Methods are not the hard part. The serialization and deserialization is, because it has to enforce all the rules that the type has. The deserializer has to replicate the parsing of the suffix, and the serializer has to perform canonicalization.
Eg, let's say we represent it as:
pub struct Quantity {
pub value: i64, // Incorporates the exponent
pub suffix: Suffix,
}
pub enum Suffix {
None,
Kibi,
Mibi,
Kilo,
Mega,
...
}This cannot be naively serialized by just serializing the value and the suffix one after the other, because Quantity { value: 1000, suffix: Suffix::None } needs to be serialized as "1e3" and not "1000", Quantity { value: 1000, suffix: Suffix::Kilo } needs to be serialized as "1M" and not "1000k", etc.
All that logic is in the files I linked above plus the go-inf library, so all of that would need to be translated to Rust and would need to be kept in sync with changes.
That will be backwards compatible I think. Or perhaps even replacing the type itself to imitate Go more closely, however that will definitely be incompatible change.
Compatibility is not a concern. Almost every release of this crate is already semver-major.
The type in question in Go is significantly more complex than just string. It might be beneficial to mimic its Go behavior in this library as well. Perhaps adding various methods similar to its Go counterpart. That will be backwards compatible I think. Or perhaps even replacing the type itself to imitate Go more closely, however that will definitely be incompatible change.