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

From: Hadriel Kaplan (hadrielk_at_[hidden])
Date: 2020-09-26 15:35:04

> On Sep 26, 2020, at 10:39 AM, Hadriel Kaplan via Boost <boost_at_[hidden]> wrote:
> 
>> 
>> On Sep 26, 2020, at 8:37 AM, Mathias Gaunard via Boost <boost_at_[hidden]> wrote:
>> 
>> What's the problem with storing it as a string or as an arbitrary
>> number when it's not representable as int64 or a double?
>> It doesn't cost anything to do this, it's a pure extension with no
>> impact on people that don't need it.
> 
> Do you mean encoding `int64_t`/`uint64_t` into JSON as a string, when either: (a) their value otherwise lose precision or even just (b) always?
> 
> Let’s call those options #4a and #4b. Obviously they can’t be default behavior because they don't round-trip.
> 
> #4a seems inconsistent behavior to me, but :shrug:
> #4b seems reasonable, as it’s a common choice people seem to make to keep precision today.

Actually, thinking about this for more than a few seconds, the problem with #4b is _all_ integers in the entire data structure would be encoded as strings, which is probably not what anyone would want. (?)

Suddenly #4a sounds reasonable. :)

In practice, what other C++ libs do is push that decision back onto the user to make - either by having a callback-based serializer, or by simply ignoring it and making the user set the values as strings to begin with. That way the user chooses which particular fields to encode as what, since only the user knows the schema and use-case.

Boost.JSON could also ignore it and push that decision back to the user, but also offer a convenient way to set a string in the json::value from an integral. For example by providing the equivalent of `std::to_string(<integral>)` but for json:string, or even a member function of json::string such as json::string::from(<integral>) or some such.

-hadriel