On Sun, Nov 17, 2019 at 3:45 AM Bjorn Reese via Boost
Before we get to that point, there are some questions
Yes these are good questions. I thought I had answered them but it could certainly use more explaining (and in the documentation as well). In terms of parsing and serialization I don't think there will be any single solution that will satisfy all use cases. The emphasis of my JSON library is on the container that represents the JSON In memory. It is designed to be useful as a vocabulary type. This means that if someone wants to write a library that does things with JSON (e.g. implementing JSON-RPC[1]), their public interfaces can confidently use `boost::json::value`[2] in function signatures and declarations for several reasons: * `json::value` is SemiRegular * `json::value` is small (16/24 bytes on 32/64 bit architecture) * `json::value` behaves predictably with respect to special members (copy, move) * `json::value` supports custom allocators (without being a template parameter) * The physical structure of the value types is designed to reduce compilation times: - No class templates - No configurability (well-defined, predictable behavior) - Strong separation of concerns * The object[3], array[4], and string[5] types, used for the underlying representation of the corresponding JSON kind, are first class types[3,4,5] * All operations provide the strong exception safety guarantee That said, parsing and serialization are still important and in this area my library is quite competitive in terms of performance. RapidJSON is currently the top-performing library for parsing and serialization using a general purpose container (I don't count SIMDJson, which produces a read-only structure). In comparison to RapidJSON, my library outperforms RapidJSON in most cases and completely blows away nlohmann [6]. This library also supports both incremental parsing and incremental serialization using caller-provided buffers, an important use-case for building high performing network programs. To my knowledge no other JSON library supports this.
These days there are a huge number of JSON libraries out there. Some focus on features (e.g. binary JSON or JSONPath), others on performance, and others on user-friendliness. What competitive edge should a potential Boost JSON library offer?
A problem that I see with some other libraries is that they attempt to do too much, resulting in poor API designs with no separation of concerns, and long compilation times. Something that I am doing these days, based on things I've learned while maintaining Beast, is to design my new libraries differently: * Keep the scope narrow: solve one problem and solve it well * Minimize the use of templates where doing so does not diminish functionality * Design with modularity in mind: minimize dependencies * Be mindful of compilation times This new thinking addresses the most common complaints that users have about Boost libraries. A planned feature is to enable this JSON library to be used without Boost simply by defining BOOST_JSON_STANDALONE. This way stubborn users who refuse to use boost because Reasons can still enjoy a wonderful JSON library.
Which use cases should a potential Boost JSON library support? Should the library work seemlessly with standard algorithms?
I'm not sure what supporting standard algorithms means, but the object, array, and string containers have interfaces that are identical to their C++20 equivalents (unordered_map, vector, and string) except that for the `object` type: * The elements are stored contiguously * Iterators are ordinary pointers, and may become invalidated on insertions and removals. * The order of insertions is preserved, as long as there are no removals. * All inserted values will use the same allocator as the container itself. * All hash, bucket, and node interfaces are removed
Should it be possible to create parser combinators? Should there be a JSON archive for Boost.Serialization? Should it replace parts of Boost.PropertyTree?
These are out of scope for my library. If parser combinators are important, they can be developed as a separate library. The same goes for bindings for Boost.Serialization and Boost.PropertyTree. Generally speaking, I think new Boost library offerings need to be more numerous, smaller, modular, and with fewer dependencies from now on. I would like to break up Beast into 4 or 5 individual libraries at some point (the logistics of that being not-yet-determined). Thanks [1] https://www.jsonrpc.org/specification [2] https://vinniefalco.github.io/doc/json/json/ref/boost__json__value.html [3] https://vinniefalco.github.io/doc/json/json/ref/boost__json__object.html [4] https://vinniefalco.github.io/doc/json/json/ref/boost__json__array.html [5] https://vinniefalco.github.io/doc/json/json/ref/boost__json__string.html [6] https://vinniefalco.github.io/doc/json/json/benchmarks.html