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

From: Hadriel Kaplan (hadrielk_at_[hidden])
Date: 2020-09-25 15:23:42

> On Sep 25, 2020, at 7:05 AM, Mathias Gaunard via Boost <boost_at_[hidden]> wrote:
> 
> On Thu, 24 Sep 2020 at 10:57, Andrzej Krzemienski via Boost
> <boost_at_[hidden]> wrote:
> 
>> My understanding of a "vocabulary type" is that it should be usable (not
>> necessarily with maximum efficiency) for *any* usage. In the case of JSON
>> that would mean that I should be able to represent any value that
>> corresponds to a valid JSON when converted to text. I do not think that
>> json::value can claim that without the ability to serialize arbitrarily big
>> numbers.
> 
> I fully agree with this statement.
> json::value *needs* to support arbitrary numbers. It's incomplete without it.

Empirical evidence would suggest otherwise. nlohmann, RapidJson, folly::dynamic, etc. do not support that. How can it *need* to support it, when other popular and useful libraries haven’t?

Even in javascript land, while there’s spec support for BigInt as a value within javascript’s language types, there’s no ECMA spec for how to encode or decode it to JSON that I know of. There are several libraries that do custom things to encode/decode BigInts to/from JSON, but none of them are interoperable. Chrome V8 engine has BigInt support I believe, for example, but does not support encoding it to JSON.

If boost.JSON were to choose its own syntax for encoding such things, it wouldn’t be interoperable with anything other than itself for that value.

And if ECMA ever does specify how to encode it, Boost.JSON would have to either change its encoding to match that and thereby break backward-compatibility with previous versions of Boost.JSON... or it would have to offer serialization+parsing options to choose the encoding, which would suck because you’d have to know which JSON encoding style you’re using for any given file/socket.

Regardless, I wouldn’t be surprised if Boost.JSON added support for holding values of larger range/precision a la Boost.Multiprecision someday, but that day does not need to be now, in my opinion.

I fully expect/hope that if Boost.JSON takes off, that more features will be added to it in the future based on demand and submitted PRs.

-hadriel