Somewhat notable is that `char8_t` is banned with very reasonable motivation that applies to most codebases:

> Use char and unprefixed character literals. Non-UTF-8 encodings are rare enough in Chromium that the value of distinguishing them at the type level is low, and char8_t* is not interconvertible with char* (what ~all Chromium, STL, and platform-specific APIs use), so using u8 prefixes would obligate us to insert casts everywhere. If you want to declare at a type level that a block of data is string-like and not an arbitrary binary blob, prefer std::string[_view] over char*.

▲

ChrisSD 5 hours ago | parent [-]

`char8_t` is probably one of the more baffling blunders of the standards committee.

▲

jjmarr 5 hours ago | parent [-]

there is no guarantee `char` is 8 bits, nor that it represents text, or even a particular encoding.

If your codebase has those guarantees, go ahead and use it.

▲

20k 4 hours ago | parent | next [-]

char8_t also isn't guaranteed to be 8-bits, because sizeof(char) == 1 and sizeof(char8_t) >= 1. On a platform where char is 16 bits, char8_t will be 16 bits as well

The cpp standard explicitly says that it has the same size, typed, signedness and alignment as unsigned char, but its a distinct type. So its pretty useless, and badly named

	▲	4 hours ago \| parent [-]
		[deleted]

▲

dataflow 5 hours ago | parent | prev | next [-]

How many non-8-bit-char platforms are there with char8_t support, and how many do we expect in the future?

▲

RobotToaster 4 hours ago | parent [-]

Mostly DSPs

	▲	dataflow 3 hours ago \| parent [-]
		Non-8-bit-char DSPs would have char8_t support? Definitely not something I expected, links would be cool.

▲

Maxatar 2 hours ago | parent | prev [-]

There's no guarantee char8_t is 8 bits either, it's only guaranteed to be at least 8 bits.