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
> 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?
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk