u8json: char aint a compatible integer type !? Differentiate between char and integer types. Proposal.

[ingo-loehken]

Background

While adapting nlohmann::json to support std::u8string (C++20 and beyond) as string_type, different problems occur, because the change in the character type is not yet represented explicitly in type_traits and apis. There is currently one test, that uses an alternative string_type, but still uses char as character-type.

C++11: Char Type Candidates

• Regarding SG-16 char and wchar_t are called ordinary char types.
• ordinary char types and charN_t are called char types.
• integral types std::uint8_t aka unsigned char and std::int8_t aka signed char

Of those char, char8_t, std::uint8_t and std::int8_t are candidates (or any enum (class) with such an underlying type). Due to lack of an explicit character type that is associated with utf8, char was for C++11 the obvious choice or (to disambiguity by type, where char may represent any encoding) unsigned char.

C++20: An Alternative: std::u8string -> u8json

Paradigmen: I would expect, that anywhere a string literal, or range or whatever is used to represent a sequence of chars is possible, only char8_t is accepted as character type to avoid Mojibake

Therefore

• ctor or asgnop from any char based sequence with u8json is rejected
• ctor or asgnop from char with u8json is rejected

This means that char should not be interpreted as a compatible integer type, but as a character type (at least for C++20 and u8json). The C++ standard defines char and bool as integral types (ofc technical the types are integral), but no one would argue about bool not beeing a compatible integer type (as most won't do for char8_t, char16_t, char32_t, which are also integral types). Therefore I argue that differentiating between char and integer types would avoid misinterpretation and should be at least mandatory for u8json ...

Example

Currently it is legal to write code like

json json_arr = {'a', 'b', 'c', 'd', 'e', 'f', 'g', 'h', '0', '1'};

with this proposal

u8json json_arr = {'a', 'b', 'c', 'd', 'e', 'f', 'g', 'h', '0', '1'}; // compile time error

and for all other character types

u8json json_arr = {wchar_t{}, wchar_t{}};  // (2)
u8json json_arr = {char8_t{}, char8_t{}}; // (3)
u8json json_arr = {char16_t{}, char16_t{}}; // (2)
u8json json_arr = {char32_t{}, char32_t{}}; // (2)

• (2) proposal: deny, because char types
• (3) proposal: deny (not an integer), for nlohmann::json it is currently interprected as nlohmann::json::array_t

I would prefer to deny all character types anywhere else (for u8json), so that the user has to explicitly state its intent not mixing number and character types.

Notify

@nlohmann

Please share your thoughts.