Re: [review][JSON] json::value as a vocabulary type

From: Hadriel Kaplan (hadrielk_at_[hidden])
Date: 2020-09-26 14:42:17

> On Sep 25, 2020, at 8:52 PM, Peter Dimov via Boost <boost_at_[hidden]> wrote:
> 
> Vinnie Falco wrote:
> 
>> So, I think at some point I will want to introduce options for serialization, and one of the options could be the treatment of integers outside the range ~+/-2^53. We could:
>> 
>> 1. serialize them as-is (current implementation)
>> 2. serialize them as the nearest representable IEEE double
>> 3. throw an exception
> 
> I can't think of a reason to ever prefer #2 over #1. "As is" is already a legitimate serialization of the nearest representable IEEE double, so #1 is a valid implementation of #2, except it doesn't needlessly throw away information.
> 
> There's no need to innovate here; we already know that preserving 64 bit integers is what's useful in practice. 

I agree with Peter that #2 isn’t useful - no library I know of in C++ does #2. (Though not that I know them all by any means, of course)

RapidJSON, nlohmann, folly::dynamic, and taoJSON, etc. all do #1 by default, regardless of precision loss on the receiver-side. folly::dynamic also offers a serialization option to do #3 (which they call `javascript_safe`).

Protobuf’s json encoder serializes `int64`/`uint64` as a string, regardless of its actual value causing precision loss or not, I think. The decoder side accepts either number or string and converts it - but obviously it can only do so because it’s controlled by its schema so it knows what the type should be.

And of course there’re some libraries that only store them as doubles to begin with (Qt’s QJSonDocument, for example).

-hadriel