Niall Douglas wrote:
For the record, I've had offlist email discussions about proposed Boost.JSON with a number of people where the general feeling was that there was no point in submitting a review, as negative review feedback would be ignored, possibly with personal retribution thereafter, and the library was always going to be accepted in any case.
Personal retribution, really?
Consider this: a Hana Dusíková type all-constexpr JSON parser could let you specify to the compiler at compile time "this is the exact structure of the JSON that shall be parsed". The compiler then bangs out optimum parse code for that specific JSON structure input. At runtime, the parser tries the pregenerated canned parsers first, if none match, then it falls back to runtime parsing.
That's definitely an interesting research project, but our ability to imagine it does not mean that people have no need for what's being submitted - a library with the speed of RapidJSON and the usability of JSON for Modern C++, with some additional and unique features such as incremental parsing. To go on your tangent, I, personally, think that compile-time parsing is overrated because it's cool. Yes, CTRE is a remarkable accomplishment, and yes, Tim Shen, the author of libstdc++'s <regex> also thinks that compile-time regex parsing is the cure for <regex>'s ills. But I don't think so. In my unsubstantiated opinion, runtime parsing can match CTRE's performance, and the only reason current engines don't is because they are severely underoptimized. Similarly, I doubt that a constexpr JSON parser will even match simdjson, let alone beat it.