Fix u64 deserialization

[litchipi]

Past issue: toml-rs/toml-rs#256

u64 cannot be deserialized as it's backed by a i64 format

This causes this to fail:

let data = format!("id = {}", u64::MAX);
let val : toml::Value = toml::from_str(&data).unwrap();
println!("{:?}", val);

And any number > i64::MAX will also fail.

[epage]

This deals with problems similar to #540

[litchipi]

Indeed, I hacked a bit around, and it just makes sense to have a Number(i64) variant to cover the everyday usage.
We could imagine some kind of variants for larger numbers, but the toml::Value enum would be much more of a burden (many variants to take care of).

I guess the best way would be to have:

enum Value {
   // other variants ...
   Number(NumberValue),
}

enum NumberValue {
  Unsigned(u64),
  Signed(i64),
  BigUnsigned(u128),
  BigSigned(i128),
  Float(f64),
}

impl TryInto<u64> for NumberValue {
  // If the variant matches, get the value, else raise an error
}

It forces an extra step to get a usable number from the toml::Value, but it covers all kind of numeric types we could want.
Seams to me like a good middle ground

[jaskij]

I'd say, a feature flag, and then simply use something like num_bigint internally.

This allows for flexibility, while not penalizing users who don't care things larger than i64. Could even be relatively simple to implement, as that crate already has serde support.

[litchipi]

Feature flag absolutely makes sense here indeed.
I may start to work on it later next week

[epage]

Feature flag was covered as one of the potential solutions in #540 but it isn't "free"

Use a feature flag for controlling this, requiring wrapping the numbers in a newtype to avoid this being a breaking change (one dependency enabling a feature shouldn't break other dependencies) which both adds implementation complexity and complexity on the users side

There are two layers we are talking about, toml which provides higher api stability serde support and toml_edit which directly exposes the parsed results. toml_edit would need to stop exposing the numeric type directly and instead provide a newtype for it.

[jaskij]

Ah, I was unaware there would be so much change. This does sound more difficult then. It would also mean adding the feature flag in toml_edit.

I still feel like a feature flag is the best solution here, but it will be a decently big undertaking, involving breaking changes in both crates.

---

After some recent changes on my end, it has become a non-issue for me.

In case somebody was curious about my use case: I used toml to directly transform the TOML into Protobuf messages using prost and prost-serde. One place in our protocol sends the first eight bytes of git SHAs using fixed64 (u64).

The use case changed, and I need to use an intermediate type for reading TOML. Since I need to add a conversion, I may as well add u64::parse in there.