Re: [JSON][review] Design: what is expected of a "JSON library"?

From: Vinnie Falco (vinnie.falco_at_[hidden])
Date: 2020-09-15 16:08:59

On Tue, Sep 15, 2020 at 8:47 AM Andrzej Krzemienski via Boost
<boost_at_[hidden]> wrote:
> ...Boost Review puts
> the bar high for the libraries, so I guess this question should be
> answered: what guarantees can a JSON library give us with respect to
> accuracy of numbers?

This is a great question. My philosophy is that there can be no single
JSON library which satisfies all use-cases, because there are
requirements which oppose each other. Some people for example want to
parse comments and be able to serialize the comments back out. This
would be a significant challenge to implement in the json::value
container without impacting performance. It needs to be said up-front,
that there are use-cases for which Boost.JSON will be ill-suited, and
that's OK. The library targets a specific segment of use-cases and
tries to excel for those cases. In particular, Boost.JSON is designed
to be a competitor to JSON for Modern C++ ("nlohmann's json") and
RapidJSON. Both of these libraries are wildly popular.

Support for extended or arbitrary precision numbers is something that
we can consider. It could be added as a new "kind", with a custom data
type. By necessity this would require dynamic allocation to store the
mantissa and exponent, which is fine. However note that the resulting
serialized JSON from these arbitrary precision numbers is likely to be
rejected by many implementations. In particular, Javascript in the
browser and Node.js in the server would reject such numbers.

As a goal of the library is suitability as a vocabulary type,
homogeneity of interface (same integer and floating point
representation on all platforms) is prioritized over min/maxing (using
the largest representation possible). The cousin to homogeneity is
compatibility - we would like to say that ANY serialized output of the
library will be recognizable by most JSON implementations in the wild.
If we support arbitrary precision numbers, some fraction of outputs
will no longer be recognized. Here we have the aforementioned tension
between features and usability. Increasing one decreases the other.

Regards