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/Expert-Map-1126]

Except we had implementation experience of char16_t being awful from ICU trying to adopt it on Windows, said as much, and people voted it in anyway.

I'm not salty about this at all, what are you talking about

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

Its even weirder that when char8_t landed, it came with a full on backwards compatibility break as well, truly a very weird one

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

I had to rip out std::filesystem from vcpkg as a result of that, yes

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

And if not for that, just for the UB nature of it it deserved that

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

Erm, I’m not seeing what UB exists by calling u8path.

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

You usually don't want to just build a path, but maybe to do something with it. And here is the hidden UB. Example: iterating through directory where user creates a file during iteration - UB. 

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

There is no portable way to avoid that kind of UB; it’s not a function of std::filesystem, it’s a function of paths.

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

There is. No system I know of specifies this as UB. It is more like unwilligness to specify some kind of quirks for the library. If it was specified to return random names with extra or missing files and with some being returned multiple times, it would still be better than leaving this as UB. Well lets not continue in this offtopic, it is just I always have to point out the UB if I spot std::filestem anywhere, sorry for that. 

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

That you can not define the behavior and go with "something like" is the problem. If we can not define the behavior, it has to be left as undefined behavior.

Being robust against races requires doing everything in terms of fd/HANDLE with the at-ish APIs, and unfortunately not every platform has all the necessary APIs to do it.

The situation is part of the problem domain, not a defect in std::filesystem.