I understand your concerns about the compatibility of future CBOR implementations, but my design is not heavy, it uses templates to use any container that meets the requirements (only requiring push_pack, emplace and some common operations), and it exposes the underling container. Therefore, algorithms that apply to the lower-level container also apply to it. For example, if you use std::vector as the underling container, then you will iterate by directly using std::vector::iterator.


________________________________
From: Thiago Macieira <thiago_at_[hidden]>
Sent: Wednesday, February 14, 2024 3:36
To: Yexuan Xiao <bizwen_at_[hidden]>
Cc: std-proposals_at_[hidden] <Std-Proposals_at_[hidden]>
Subject: Re: [std-proposals] A Minimal JSON Support Library for C++

On Tuesday, 13 February 2024 11:28:04 PST Yexuan Xiao wrote:
> CBOR has nothing to do with the proposal. First of all, CBOR and JSON are
> two different standards, CBOR is not a new version of JSON. Secondly, users
> use JSON, not CBOR.

I know they aren't the same. And there are users of CBOR. Not as many as JSON,
but they exist, especially in the more embedded / constrained environment
(CBOR came out of the IETF CoRE WG). There's no sense in spelling "false" with
5 bytes if one works.

But you're still missing the point: the fact that CBOR exists means there's
value in having reusable knowledge and even reusable algorithms (where
applicable) that apply to both. You need to explain in your proposal why
restricting to only JSON is a good idea, because there will be people asking
why not.

And especially why an API to store the types without parsing or encoding
again.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel DCAI Cloud Engineering