On Sun, Nov 24, 2019 at 12:26 AM Julien Blanc
Not sure why you say this is an innovation. Maybe i missed something, but i dont see this much different than https://doc.qt.io/qt-5/qjsonvalue.html , which is around for years.
"Not much different" is still different, and those differences are enough to disqualify QtJsonValue from being a vocabulary type: * QtJsonValue does not support allocators * QtJsonValue has an "undefined" state[1], reminiscent of valueless variants. * QtJsonValue is part of a huge application framework. This alone is enough to make it unsuitable as a vocabulary type: No one is writing libraries that depend on Qt (imagine a Boost library being proposed that required Qt).
While it is ok for most use cases
Yes and these are the use cases which my library addresses.
But the nice thing is that from what i see, it is entirely possible to do with current boost.json (didn't check about the serializer part, though).
I don't think so, the parser in boost.json is a SAX parser which is somewhat inconvenient for parsing directly into user defined types. It could be adapted into a generator using coroutines however.
Using json types directly is fine for prototyping, for quickly written code that is not supposed to last for years. There is a market for this, this is useful. However, i would not rely on it for any code that is supposed to last or be reused amoung projects.
Counterexample: https://github.com/ripple/rippled/blob/232975bfdbde12a65499130d78f938f261c98... There are others. Thanks