Re: [review][JSON] Review of JSON starts today: Sept 14 - Sept 23

From: Vinnie Falco (vinnie.falco_at_[hidden])
Date: 2020-09-15 14:35:02

On Tue, Sep 15, 2020 at 7:14 AM Rainer Deyke via Boost
<boost_at_[hidden]> wrote:
>    - The choice of [u]int64_t seems arbitrary and restrictive.  It means
> that Boost.JSON will not use a 128 bit integer even where one is
> available, and it means that it cannot compile at all on implementations
> that don't provide int64_t.  It's good enough for my purposes, but I
> would like to see some discussion about this.  The json spec allows
> arbitrarily large integers.
>
>    - On a similar note, the use of double restricts floating point
> accuracy even when a higher-precision type is available.  The json spec
> allows arbitrarily precise decimal values.

The spec gives implementations freedom to place arbitrary upper limits
on precision. To be useful as a vocabulary type, the library prefers
homogeneity of interface over min/maxing. In other words more value is
placed on having the library use the same integer representation on
all platforms than using the largest integer width available. Another
point is that the sizes of types in the library is very tightly
controlled. `sizeof(value)` is 16 bytes on 32-bit platforms and 24
bytes on 64-bit platforms, and this is for a reason. It is to keep
performance high and memory consumption low. There is a direct, linear
falloff in general performance with increasing size of types.

>    - boost::json::value_to provides a single, clean way to extract
> values from json, but it also renders other parts of the library (e.g.
> number_cast) redundant except as an implementation detail.

Well, number_cast isn't redundant since it is the only interface which
offers the use of error codes rather than exceptions. We could have
gone with error codes in conversion to user-defined types but then the
interface would need some kind of expected<> return type and things
get messy there. Exceptions are a natural error handling mechanism.
However we recognize that in network programs there is a need to
convert numbers without using exceptions, thus number_cast is
available.

>    - boost::json::value_to provides a single, clean way to extract
> values from json, but it's syntactically long.  The same functionality
> in a member function of boost::json::value would be nicer to use.

Algorithms which can be implemented completely in terms of a class'
public interface are generally expressed as free functions in separate
header files. If we were to make `get` a member function of
`json::value`, then users who have no need to convert to and from
user-defined types would be unnecessarily including code they never
use.

Thanks