On 8/25/25 1:54 AM, Thiago Macieira wrote:
> On Sunday, 24 August 2025 09:01:28 Pacific Daylight Time Jan Schultke wrote:
>> We don't even have a cross-platform way to bundle char* with some enum which
>> specifies the encoding of the string. There's not a single function in the
>> C standard library that would let you bundle char* with encoding.
> That's what all those _l functions are for.
>
>> Given the total absence of any sound and portable functionality, given that
>> we're basically starting from scratch (not counting OS-specific
>> functionality), we may as well design it properly, with a type that is
>> intended purely for UTF-8 text, as compared to char, which is a bit of an
>> integer, a bit of a byte type, and a bit of a text type with unspecified
>> encoding, but ... maybe UTF-8. Why can't we have the sound design that
>> virtually every language after C++ managed to get right?
> I agree it's unfortunate that char is both a character and an integer, plus
> the free "get out of jail" card for type aliasing.
>
> As I pointed out in the other email: the choice here should be UTF-16, not
> UTF-8. That would get immediate and unconverted access to ICU, Win32 and
> Cocoa/CoreFoundation APIs.
>
> I don't mind there being char8_t-based APIs. It would be good to have them.
> But char16_t should be of higher priority. At least everything that is
> supported via char8_t should be supported in char16_t.

I strongly agree that the standard should support char16_t at the same
level as char8_t.

Part of the current struggle is deciding to continue doing what we did
for std::filesystem and provide interfaces for all of char (in current
locale encoding or environment locale encoding or literal encoding or
...), wchar_t, char8_t, char16_t, and char32_t or to reduce the
encodings exposed in such interfaces to just char8_t and maybe char16_t
to reduce the burden on C++ implementors.

Tom.