Consider keeping floats and ints as strings, and not parsing them

[nik-rev]

Suggestions:

• Instead of storing KdlValue::Float as f64, store it as String
• Instead of storing KdlValue::Integer as i128, store it as { repr: String, radix: u32 } where the radix can only be 2, 8, 10 or 16

This should make the library both simpler implementation-wise, but also more versatile

Since kdl parser can be used for any purpose, it should be up to the user of the crate to decide how to parse the values

This would improve performance because it would remove an unnecessary step in certain situations: The KDL library converts the int/float to a string, but then we have to .to_string() it back.

There is no logical distinction in KDL between real numbers, integers, and floating point numbers. It's up to individual implementations to determine how to represent KDL numbers.
from the spec

Given the above, i should be able to represent an i1024 or f512 in KDL by using the kdl crate - or any sort of number, but this is currently impossible

One difficulty with this approach is: What do we do about #inf, #-inf and #nan?. Personally, I think they could be represented by adding 2 new variants to KdlValue - KdlValue::Inf { is_positive: bool } and KdlValue::NaN.

[zkat]

The intention here was to use what other things similar to serde_json::Value use in the Rust ecosystem. The intended, "proper" solution to this issue is actually #71, which will get you the exact type you want, not just numbers.

I didn't really write the general-purpose KdlDocument for performance-sensitive scenarios. You would probably want something similar to #98 (or something more like SAX) that would let you skip things altogether or transform them purely based on their text value, rather than something that loads the entire document into memory like KdlDocument does.