Ed Page

The problem with the former is you might need to mix and match things (separators and radix) and that explodes the combinations that could exist. That is a benefit to...

Bah, typo on my part. I'd like it to be a `struct`, not an `enum`. `struct`s expose less implementation details so we can more easily evolve it. btw another angle...

Looking good! I think I'd put a `pub fn format(self, value: N) -> TomlInteger` on `TomlIntegerFormat` so people only have one type to directly work with, rather than two. In...

> A TOML integer is an i64, so maybe Into might suffice: `i64` support is a recommendation. The language within the spec is being clarified in toml-lang/toml#1058. While `toml_edit` only...

If a trait bound like that works, then great! Otherwise, the problem will be caught by the fact that `TomlInteger` does not support `WriteTomlValue`. btw feel free to prepare and...

Thanks for @pastelmind, toml_writer-v1.0.1 is now out with `TomlIntegerFormat` for customizing how to write an integer. While this doesn't mean there is support in `toml_edit`, that can be worked around...

If I'm reading this correctly, this is a bug in deserializing a `toml::Value` into a struct as opposed to deserializing a `&str` into a struct.

Hmm, Should we always create a `String` / `Box`? There would be no performance difference for non-error recovery cases. For error recovery cases, it would be an allocation per error....

The string is not related to an error message but is a copy of the input itself to allow for annotating it in error messages, so `&'static str` wouldn't work.

Could you explain why "least powerful" would be our criteria for which string type to prefer?