On 8/26/25 4:39 PM, Thiago Macieira via Std-Proposals wrote:
> 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
>> forstd::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 char/N/_t support for std::format and friends is
lack of locale support for char/N/_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 char/N/_t. I don't know
how problematic that might be.

Tom.