-
Notifications
You must be signed in to change notification settings - Fork 103
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix u64 deserialization #705
Comments
This deals with problems similar to #540 |
Indeed, I hacked a bit around, and it just makes sense to have a 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 |
I'd say, a feature flag, and then simply use something like This allows for flexibility, while not penalizing users who don't care things larger than |
Feature flag absolutely makes sense here indeed. |
Feature flag was covered as one of the potential solutions in #540 but it isn't "free"
There are two layers we are talking about, |
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 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 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 |
Past issue: toml-rs/toml-rs#256
u64
cannot be deserialized as it's backed by ai64
formatThis causes this to fail:
And any number
> i64::MAX
will also fail.The text was updated successfully, but these errors were encountered: