On Tue, Sep 15, 2020 at 7:14 AM Rainer Deyke via Boost
- 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