Date: Tue, 13 Feb 2024 10:57:10 -0800
On Tuesday, 13 February 2024 10:46:57 PST Yexuan Xiao via Std-Proposals wrote:
> That’s why my proposal does not include a parsing API, it leaves it entirely
> to the user (or future proposals). It focuses on how to precisely represent
> JSON, and how to manipulate it.
That's still not enough. You glossed over the character support that Tiago
mentioned. Your code had:
json j15{ "bbb"sv };
Why not char8_t? Why not char16_t? Why not char32_t? Why not all of them?
Plus, wouldn't it be nice to have compatibility with CBOR too for the data
representation?
> That’s why my proposal does not include a parsing API, it leaves it entirely
> to the user (or future proposals). It focuses on how to precisely represent
> JSON, and how to manipulate it.
That's still not enough. You glossed over the character support that Tiago
mentioned. Your code had:
json j15{ "bbb"sv };
Why not char8_t? Why not char16_t? Why not char32_t? Why not all of them?
Plus, wouldn't it be nice to have compatibility with CBOR too for the data
representation?
-- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel DCAI Cloud Engineering
Received on 2024-02-13 18:57:12