On Thu, Feb 15, 2024 at 12:27 PM Thiago Macieira via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> On Thursday, 15 February 2024 09:13:37 PST David G. Pickett via
> Std-Proposals
> wrote:
> > JSON may be newer than linked list, tree, hash table, linefeed separated
> > text, CSV, XML but it makes sense to have standard library support for a
> > reasonably common need and a standardized file/string. Many tools
> written
> > wholly or partially in C++ deal with JSON: browsers, RDBMS, JAVA,
> > JAVAScript interpreters.
>
> Then the proposal text needs to provide a survey of what the needs are and
> how
> it fulfills the requirements of the existing tools. It needs to provide an
> overview of what the state-of-the-art is and how the proposed solution
> compares.
>

+1, and also, OP said a few times that he's not interested in text
processing — which is literally the entire point of JSON!
It seems like OP has implemented an in-memory data structure more or less
equivalent to std::map<std::string, std::any>; but the point of JSON isn't
the in-memory data structure, it's the *parsing from text* and *serializing
to text* (i.e. what Python calls `json.loads` and `json.dumps`). If the
library can't do those things — i.e. read and write JSON — then it's *not*
a JSON library.
If someone were to come here and advertise their "CSV library" that didn't
read or write CSV files, or an "XML library" that didn't read or write XML,
they'd get a similarly chilly reception.

my $.02,
Arthur