On Thu, Sep 17, 2020 at 11:10 AM Andrzej Krzemienski via Boost
I recommend to *ACCEPT* the library into Boost.
Thank you for your time and thoughtful comments.
3. String has two sections "Member Functions": https://master.json.cpp.al/json/ref/boost__json__string.html
That's a bug in the doc toolchain, the 2nd section is "Static Member Functions" (max_size is static)
4. Documentation for value::operator= seems corrupt: https://master.json.cpp.al/json/ref/boost__json__value/operator_eq_/overload... * it has sections with no content
Just a case of missing text, fixed here: https://github.com/CPPAlliance/json/blob/75794a7f372fb36225946c989d2ca6cdb6d...
5. Examples of input JSON-s contain a lot of escape characters in string literals, like in https://master.json.cpp.al/json/usage/conversion.html
I'm not happy with this section at all, it needs a rewrite.
6. Some functions (like operator== or swap(x, y)) are naturally part of class interface, even though they are not member functions. It is annoying and confusing that rather than being listed along with the class they belong to they are instead listed separately as "free functions"
Yes I know what you mean, and this is a limitation of the doc scripts I am using. `operator==` is an inline friend to accelerate overload resolution, but `swap` is not. I can make `swap` an inline friend as well, if that doesn't cause any problems (with respect to the rules of C++).
2. Boost.JSON provides its own string type. This begs a lot of design questions for `json::string`. Is it a better replacement for std::string? std::string provides the following capability: ... json::string does not. How do I do a similar thing with json::string?
json::string is a better replacement for std::string for use as a type in the variant, because it is optimized to work with the library. As for the initializer_list<char> overloads, well - I have my doubts that these are used outside of toy examples, but if a user complains then I guess we would add them.
3. string::swap() has a strange precondition: you cannot swap an object with itself https://master.json.cpp.al/json/ref/boost__json__string/swap.html
Just open an issue and explain how you think self-swap, self-move, and self-assignment should work and I will make the changes.
4. I do not like the 2-state-switch mechanics of BOOST_JSON_STANDALONE. It assumes that a user either wants a no-Boost version or that she wants a package: all Boost components.
But what if I am using C++14 and I want to use std::error_code and Boost-emulated memoty_resource and string_view? What If I use Boost version and C++17 and want to use std::string_view?
Maybe you can additionally provide macros for turning Boost-emulation libraries one-by-one? I mean, one for string_view, one for error_code, and one for memory_resource.
Well, I don't like having two versions of error_code, two versions of string_view, two versions of memory_resource, two versions of Asio, and so on. If 90% of the C++ community was using C++17 or later, Boost.JSON might *only* have the standalone mode. In other words, I would probably not support boost::system::error_code and other Boost types. This of course is assuming that Asio was using the std equivalents rather than the Boost versions which it currently uses. Practically speaking, C++11 and C++14 have enough users that supporting them makes sense. Thus what I have done is create two modes. The "standalone" mode, which users must opt-in to, and the Boost mode which is what you get by default. Note that these are two distinct libraries with their own set of symbols. Both versions can co-exist in the same executable, without getting link errors. This is accomplished through inline namespacing. At some point, Boost is going to have to holistically address this issue of having its own substitute types for commonly used std types. But for now I think it is best that users make a choice to either go all-in on Boost types, or simply go with C++17 and have all-std types. I would like to avoid enabling users to proliferate more code that mixes and matches the Boost types with the std types. Thanks