`toml` 0.9: `DeInteger` and `DeFloat` are awkward to use

[Jarcho]

Neither DeInteger nor DeFloat have an easy way to get their parsed value. to_string().parse() can (almost) be used, but that's not really a great interface. The existing to_* private would do the job.

Parsing almost works because integers are prefixed and that needs to be handled separately.

[epage]

Yes, the API is currently incomplete.

However, I'm unsure what I want to expose.

You suggest exposing the to_<type> functions. But we have four of those for DeInteger. That is because that is what we need for our implementation. An API should be bound by principles and not by internal implementation. But what accessors do we provide? I'd rather not provide them for every integer type.

Some thoughts

• DeInteger::to_i64 and DeFloat::to_f64 as those are the minimum recommended types to support per the TOML spec
• DeFloat::as_str and let people do what they want
  • Hesitant about DeInteger::as_str because it also needs the radix. Maybe expose the radix number?

[Jarcho]

You could use TryFrom as the API for primitves. How to parse them is mostly unambiguous and I don't think you can get anything easier to use than .try_into().

Exposing something like as_str will still be needed for BigFloat/BigInt parsing. How a string representation is exposed does have questions (e.g. underscores and integer prefixes), but these don't need to be answered to handle primitives.

[epage]

DeInteger and DeFloat have _ removed. DeInteger has the prefix removed.

[Jarcho]

I guess that solves the string questions unless there are other oddities allowed by the toml spec.

[epage]

0.9.4 is released with as_str access.

[Jarcho]

Thank you.