On Wednesday, 8 July 2026 09:17:02 Pacific Daylight Time Tiago Freire wrote:
> You write the following code:
>
> auto text = "rw";
>
> you write that text to file. You then you open that file with a text editor
> interpreting it as utf-8. Will it read "rw"? The standard doesn't say
> anything, maybe it will, maybe it won't.

Correct. But irrelevant point.

First, I/O is entirely out of scope of the Standard. How bytes get interpreted
by someone else has never been and is unlikely to ever be part of the
Standard.

Second, for 99.999% of people writing that code above, it is UTF-8 (note I
added another 9). Including on Windows (except for file names) and z/OS, and
including if they used non-ASCII characters.

So while the Standard is silent on how to do this right, it's already a solved
problem in practice.

> If you print that to the console
> or create a file with that name, will it read "rw"? Probably yes. If you
> use that as flag to open a file will it have read/write permissions? Yes!
> If instead you do
> auto text = u8"rw";
> If you open with the text editor as utf-8, the standard says Yes, it will
> absolutely read "rw".

Except of course we have no API to read() and write() char8_t literals. I must
reinterpret it as bytes in order to do that. Note how we didn't need to do
that in C++11 and C++14.

Also, if your text editor can choose encodings, then the narrow-charset "rw"
is likely going to be interpreted properly everywhere, even in an environment
that mixes EBCDIC and ASCII.

> If you use that as flag to open a file will it have
> read/write permissions? UB!

There is no fopen(const char8_t *, const char8_t *). If you meant calling
fopen(), then you did that reinterpret_cast trick, which is pointless. You
intentionally shot yourself in the foot. The solution for that is easy: just
don't.

> I'm not proposing to add char8_t APIs to operate with the OS like the file
> system. I'm against that. I'm just talking about processing text. That's
> it.

I understand, but my point about being something that people will want to use
when the problem is already mostly solved for most people remains. Yes, there
cases where the "everything is UTF-8 doesn't work". Are they worth the
committee's time? Will the solutions be adopted by C++ developers?

Or are they like the architectures that aren't two's-complement? We ignore
they exist and dictate that the implementation must pretend it is.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
  Principal Engineer - Intel Data Center - Platform & Sys. Eng.