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.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
  Principal Engineer - Intel Platform & System Engineering