On Wed, 8 Jul 2026 at 14:28, Tiago Freire <tmiguelf@hotmail.com> wrote:

> In which way may my approach not be supported?

 

In whatever which way in the future a decision needs to be made that is incompatible with your usage.

 

Ex.

Should string literals with large Unicode code points be allowed? Nope, those are UB.


Are you kidding me? When does C++ begin to break working code this way?

And there is never UB. [lex.string] says (my emphasis):

The sequence of characters denoted by each contiguous sequence of basic-s-chars, r-chars, simple-escape-sequences ([lex.ccon]), and universal-character-names ([lex.charset]) is encoded to a code unit sequence using the string-literal's associated character encoding.
If a character lacks representation in the associated character encoding, then the program is ill-formed.


 If I'm to create a plain transcoding function that converts from utf-8 to utf-16 which is the type used to represent utf-8? char8_t, char should not be supported. You want to use std::string? That's on you, you can reinterpret_cast it if you want, but you are ultimately responsible to figure out what the right thing is, and it has been discussed your approach will not work on every system.


Of course I honour objects, otherwise I would simply cast u8string& to string& and call the job done. Exactly the fact that we should not do this makes the lack of I/O support a show-stopper to me. What I said was simply using string to store UTF-8 sequences (completely valid), and use I/O functions to input/output them (completely valid).

 

Essentially on any feature that we are yet to come up with in the future every time a decision needs to be made, char8_t is utf-8 and char isn't. What that is we may not know yet, but the decision is already made.


Where does the standard say char cannot be UTF-8? And mainstream implementations can all make the working encoding be UTF-8.

 

The introduction of char8_t has solved portability problems that char has.  The wishy washiness of the arithmetic properties of char makes algorithms involving it not portable, char8_t was a god send for portability.


No, it is a pain in reality. It sounds like a good idea, but turns out to be more trouble than benefits.

You may call it opinions, instead of facts. I do not claim it to be facts. But you have made fact-like statements above that have no supporting evidence at all.

 

And I like that char8_t creates a clear type system distinction from char, so that I know which domain I’m operating at and what to expect.

Aliasing u8string to string, it wouldn’t just be inconvenient, it would actually break code.


In what way is u8string not a string in real use cases? Of course, the contrary may not be true.
 

The lack of IO and formatting support in the standard makes for a usability problem. But that is because the formatting and IO in the standard are bad, it’s not because char8_t is bad.


I can live without type strictness for UTF-8-ness. I cannot live without I/O support.

Lack of I/O support is a huge problem. It makes u8string pretty much useless to me. And there are also huge compatibility problems with char/string based code. It is much easier to require everyone to use UTF-8 than 1) dealing with string and u8string simultaneously, or 2) changing all string code to use u8string.

Both 1) and 2) are very painful. Much more painful than the apparent beauty of having UTF-8 type strictness.
 

We should fix the bad parts, not throw way the good parts because they don ‘t work with the bad parts.


The car works with the "bad parts". The car does not work with the "good parts". And you are requiring people to use the so-called "good parts"?

If the problems are not fixed, the "good parts" are not that "good".

 

Maybe what we need is for a group of people to just go ahead make a library that works independent of the standard, have that be widely adopted, and when that happens then people will get it. And then people will go like “oh, that’s how you are supposed to use it, we want to do like library X” tand it clicks, and then you can adopt something in the standard because everyone gets it.


Even if the I/O problems are fixed, they are still a small part of the problem. The reality remains that there is a huge amount of char/string-based code, and char8_t/u8string simply does not work with it.

Type strictness turns out to be not that usable in this case.

-YW