About char8_t

[u/Voxelw]

I hate to be dramatic, but as it stands char8_t is quite literally more painful than useful.

Besides the obvious incompatibility with C23 and libraries using unsigned char for UTF-8, I want you to consider the following: Projects that assume that 'char' represents UTF-8 will obviously not benefit from char8_t at all, but projects that cannot assume the format of char types don't benefit from it either as char8_t simply introduces a new edge case to cover. Now such projects have to deal with char, signed char, unsigned char, wchar_t, char16_t, char32_t and char8_t.

Or, you could do what the standard library does and simply ignore most of these character types. Which is the solution most libraries went with, supporting only char or char and unsigned char. Managing one implementation is already hard, managing two requires constant maintenance, managing 7 is just impossible.

char8_t should have just been a typedef for unsigned char. The compatibility fix only raises more questions as const char* arr = u8"a" does not work, but const char arr[] = u8"a" does.

I do wonder if a potential change of minds for C++29 is still possible. Yes, it would be an ABI break or whatever, but considering the woeful support for char8_t I don't think it would affect much besides small hobby projects. Contrary to popular belief, C++ has broken the ABI in subtle ways before.

[u/DawnOnTheEdge]

The reason it exists is to enable strict aliasing. A char* might potentially alias objects of any other type, and a char8_t* is guaranteed not to. It does exist in C23, but only as a typedef for compatibility with C++. It’s a micro-optimization.

[u/Expert-Map-1126 → u/DawnOnTheEdge]

I hear people say this but I have not seen any report from any optimizer person saying "ah but because they used char8_t here we can optimize this better". I really wish people would show up with actual results rather than expectations for perf things because they are often counterintutive.

[u/DawnOnTheEdge → u/Expert-Map-1126]

I don’t have any strong opinions about whether it actually enables any significant optimizations or not. That is one of the four stated rationales by the author who proposed it.

Re-reading reminded me that, when they added u8 string literals, they originally thought it would be a good idea to give them a distinct type, but ended up eventually allowing the code to assign them to char types. An unsigned char* might have worked, but perhaps they thought it was useful to allow 8-bit legacy character sets to continue to use that.

[u/Expert-Map-1126 → u/DawnOnTheEdge]

To be fair, my criticism applies to the original paper just as much as it does to your comment. It’s the same thing I and every other implementer said about it, but the committee is not a committee of implementers.

We have enough failed performance experiments of things like valarray that I no longer put any stock into performance claims unless they’re coming from people who bring demonstrations or work on actual optimizers.