[JSON][review] Design: what is expected of a "JSON library"?

From: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2020-09-15 15:46:30

Hi Everyone,
This is not a complete Boost Review yet. In this email I wanted to discuss
the design goals of the library.

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.

Can I expect of a JSON library that when it converts a JSON contents into
internal representation and then back to JSON contents, I should get the
same contents (moduo white space)? This would be possible if the internal
representation of JSON numbers was an arbitrary-precision decimal type or a
string. But when we need to squeeze any number into 24 bits, we will soon
get to the point when integer number `100000000000000000000001` after the
experiment gets changed to `1E23`. Is this acceptable for a JSON library?

But maybe it is not a valid goal? Maybe the goal of the JSON format is to
have objects already created in internal representation converted to text
and then back to objects? (assuming the recipient program is run on the
same environment as the sender (no differences in word size or maximum int
representation.) That is, as long as you agree to the constraints of
json::value, whatever you manage to put inside, we guarantee that you get
the same value when you serialize it and then parse it back. Boost.JSON
does this nicely.

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.

Do you get the concern that I am seeing? I mean I have used JSON libraries
before, and this has never been a practical problem. But Boost Review puts
the bar high for the libraries, so I guess this question should be
answered: what guarantees can a JSON library give us with respect to
accuracy of numbers?

Regards,
&rzej;