On Tuesday, 26 August 2025 11:40:38 Pacific Daylight Time Tom Honermann wrote:

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.

I'm arguing that for anything *text* it should be "char16_t, char, maybe 
char8_t and implementation-defined anything else" (thus allowing Windows 
environments to provide wchar_t support, as it's the only environment where 
wchar_t is realistically used, through a simple reinterpret_cast to char16_t).

The big example here is <format>: it currently supports char and wchar_t. That 
renders it mostly useless for Qt. To support it, we need to roll our own of 
almost everything, like for example <chrono> formatting. It's not worth it, so 
we are not adopting <format>.

The current hold up for charN_t support for std::format and friends is lack of locale support for charN_t. We have talked about a short term fix of making use of locale dependent features ill-formed so that we can at least provide minimal std::format support for charN_t. I don't know how problematic that might be.

Tom.