From: Mathias Gaunard (mathias.gaunard_at_[hidden])
Date: 2020-09-18 09:27:47
On Tue, 15 Sep 2020 at 16:46, Andrzej Krzemienski via Boost
<boost_at_[hidden]> wrote:
> The point that I would like to raise is the tension between having
> relatively small types (int64_t, uint64_t, double) represent numbers in
> json::value on the one hand, and ECMA specification allowing arbitrarily
> big/precise numbers in JSON format on the other.
As far as I'm concerned any JSON library that doesn't address this is defective.
It's not rocket science: just allow access to the actual string
representation, don't try to convert it to a bunch of random types.
This library doesn't even provide it in its low-level API and forces
undesired conversion to int64/double onto users.
Parsing text in general should only be in charge of segmenting the
text, not synthesizing attributes from those segments.
> In that other view, if I have objects of types
> `boost::multiprecision::cpp_int` my only option is to pass them as strings
> in JSON protocol. But I can pass any number as string anyway, so what is
> the use of numbers in JSON format? Uness it is just practical: you can
> choose to use numbers and then internal representations of JSON may be
> smaller.
I personally do encode my decimal numbers (which have values that are
not representable as double) as numbers in JSON.