On Thu, 15 Feb 2024 at 19:27, 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.

Some people don't necessarily need that to answer the question "would
it be nice if C++ implementations
had JSON support out of the box?" However, some of them will ask "why
don't you have an existing library
that's written and designed as close as possible to the C++ standard
library style, so the proposal would
just be 'standardize this existing practice here', instead of coming
up with it as we go?"

Coming up with it as we go is fine for novel things, like STL
originally, for even Ranges, for Senders and Receivers,
for which the proposal is already plausibly above previous
state-of-the-art. I'm not convinced that necessarily applies
to JSON support, but I would of course be happily proven otherwise.

I don't have a good estimate on whether the committee's library design
review groups would find it a worthy exercise,
despite being a long-time member of the committee. There's plausible
arguments for it and against it.