On Tue, 15 Sep 2020 at 16:46, Andrzej Krzemienski via Boost
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.