Date: Tue, 19 Aug 2025 17:09:04 -0700
On Tuesday, 19 August 2025 13:47:53 Pacific Daylight Time Lénárd Szolnoki via
Std-Proposals wrote:
> I think this is also a major hurdle in adopting char8_t when a ton of
> existing libraries already store utf8 strings in char arrays.
Echoing this part. char8_t by itself is useless to me: all char arrays are
UTF-8 if they contain text. I don't need a different type to tell me that and a
different type only makes things worse if everything where I need it is based
on char (std::string, std::string_view, C API, QByteArray, etc.)
u8"" producing char8_t string literals is a net negative in the Standard (in
my opinion) because it made u8"" useless. Some previous code still compiles
with C++20 and some does not, and the rules for which are not obvious. I'm not
vocal about it because I have no use for u8"": for all I care and support, ""
produces UTF-8.
This is almost the same for std::float32_t and std::float64_t, though there's an
important difference: those types don't promote.
Std-Proposals wrote:
> I think this is also a major hurdle in adopting char8_t when a ton of
> existing libraries already store utf8 strings in char arrays.
Echoing this part. char8_t by itself is useless to me: all char arrays are
UTF-8 if they contain text. I don't need a different type to tell me that and a
different type only makes things worse if everything where I need it is based
on char (std::string, std::string_view, C API, QByteArray, etc.)
u8"" producing char8_t string literals is a net negative in the Standard (in
my opinion) because it made u8"" useless. Some previous code still compiles
with C++20 and some does not, and the rules for which are not obvious. I'm not
vocal about it because I have no use for u8"": for all I care and support, ""
produces UTF-8.
This is almost the same for std::float32_t and std::float64_t, though there's an
important difference: those types don't promote.
-- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Principal Engineer - Intel Platform & System Engineering
Received on 2025-08-20 00:09:14