`toml_edit` support for integer types u64, i128, u128

[threema-mike]

Hello toml_edit team,
For context, I am using toml_edit to write out TOML files with comments, generated from annotated Rust structs.
Since we want to be able to also use big integers for certain config options, and the toml crate supports big ints, I figured I'll try to get it working for toml_edit too.
This is a discussion basis, I assume that you might want to feature-gate it or follow a different approach. I am open to discuss and adapt to the needs.

For my use-case those changes make it work for serialising and deserialising, this is therefore a working proof of concept.

My current changes can be seen in the following comparison main...threema-mike:toml:bigint-support

[epage]

Note that "big integers" and u128 are different. "big integers" usually implies variable width.

toml only supports 128-bit integers in the low level parser and serde, not toml::Value. Big integer support is weirder because there is no serde data model for it.

Keep in mind that

• adding support is a breaking change and we need to decide when to do that
• features should be additive
• features are not user friendly and we should have solid reasons to use them
• all integers are the same type in toml
• enum variants are public and limit api evolution

[epage]

Another potential path is an Integer type much like serde_json::Number

[threema-mike]

Would you envision to replace toml::Value::Integer and toml::Value::Float with toml::Value::Number that behaves like serde_json::Number or just tune up Value::Integer to hold an enum instead of a i64? (basically like my current hack with BigInteger but only one Integer variant)
I thought about doing that, but that would be a noticeable breaking change. My current approach is adding the functionality on top, it's ugly but I think non-breaking, or at least not breaking common use cases.

I agree with the attitude that u64 should not be a human editable value in a config file in the first place, which is the pro argument for i64 being sufficient. However we often deal with stuff where one wants to serialise e.g. std::time::Duration or similar into a config, which historically was solved using u64, in order to be backwards compatible we need it. And I guess that we're not alone with that problem.

[epage]

Adding new enum variants is a breaking change because people can exhaustively match them.

I specifically said an Integer because TOML treats Integers and Floats separately, unlike json.

We could also future proof by adding a Float.

Note that Number is a struct, not en enum.