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>.

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