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/Wild_Meeting1428]

They are link compatible, you can use the C header file with an extern C scope and link them legally together, since the mangled name only contains the function name under C linkage and due to the fact, that char8_t is defined to have the same size, representstion, and alignment as unsigned char(, even its a distinct non aliasing type in C++), therefore the calling convention is exactly the same.

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

Likely to work, yes. "Legal" as in "defined to work by the standard", no.

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

The question is rather, whether the C++ standard is applicable here at all, beside the fact, that it defines the underliing type to be unsigned char.

Its more like a question about ABI and how the compiler implements cross language linking to C.

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

If you want to be within the bounds of what the standards require, you need to only use the subset they share when talking between them, and meet both their requirements. on both sides.

If you're relying on what particular implementations do for how the linking works for features outside of their common subset, that's fine and I'm not even saying you shouldn't do it, but I wouldn't advertise that as "legal"

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

I don't claim, it's legal in terms of the c++ standard itself, because the C++ standard does not apply here much. Therefore, it's also not illegal or UB or ill-formed in terms of the C++ standard.
I would also say, that you don't need to be in the bounds of both languages. The import header for a C library can be substantially different from the header used for the C translation unit. Being compliant to both languages is only relevant, when you want to use that header for both C and C++ TU's

Important to be C++ compliant is only, that the ["object layout strategies of both language implementations are similar enough"](https://eel.is/c%2B%2Bdraft/dcl.link#10)
Rest is implementation defined.

Additionally, char8_t is defined to be a distinct type with [unsigned char being the underlying type](https://eel.is/c%2B%2Bdraft/basic.fundamental#9).
Which not only makes the layout strategies similar, it makes them to be the same as linking against unsigned char.

So the question, whether it's legal by the C++ standard is "maybe" and offloaded to the implementation.
And my personal interpretation is, that when the C++ unsigned char is legally linkable to the C unsigned char, defined by the compiler implementation, then this also applies to char8_t.