On Tue, Sep 24, 2019 at 2:29 AM Mathias Gaunard
Features that matter to me: - no allocation, ever - parsing/generating data incrementally from/into segmented buffers without copying - full arbitrary-precision decimal support without imposing a decimal representation on me - not imposing any string or blob type - fast conversion between numbers and text, with correct shortest representation for floating-point
These are all features of a JSON parser. As I said earlier, I think the parser is the least interesting part of a JSON library. There are already a bunch of parsers that do exactly what you are asking above. Since parsers are unlikely to appear in public interfaces, there is little value in standardizing on a particular one. Library interoperability is not enhanced in this case. What we are missing, is a robust *container* for storing JSON values. Having a great container for representing all or part of a JSON document does make it easier to write interoperable library components that work with JSON. A library that implements the JSON-RPC specification [1] may have a function with this signature: // Validates and extracts a conforming JSON-RPC request from the // specified JSON object. Throws an exception if the request is not // conforming rpc_call get_rpc_request (boost::json::value& jv); For this to work, boost::json::value needs to be a good general purpose JSON container that satisfies most users. We can never satisfy ALL users; some design choices must represent tradeoffs between conflicting goals. The library I am providing, to propose to Boost eventually, places emphasis on the design of the JSON container because this is the surface which will be exposed between libraries. It is this part that hopefully will stimulate the growth of an ecosystem of libraries which use JSON and interoperate. A final example, someone may use Boost.Beast and Boost.JSON to implement a generic RPC client or server library, taking care of the socket and connection management, making requests and receiving responses. Users of such a library will care little about the parser it uses, other than that it exists and works. But they will care very much about the types used to represent JSON data, since they will be interacting with it regularly to implement their business logic. Regards [1] https://www.jsonrpc.org/specification