Hi Jonathan,

On 2026-06-26T15:17:25+0100, Jonathan Wakely wrote:

On Fri, 26 Jun 2026 at 15:14, Alejandro Colomar via Std-Proposals
<std-proposals@lists.isocpp.org> wrote:

Hi Thiago,

On 2026-06-26T07:10:30-0700, Thiago Macieira via Std-Proposals wrote:

On Friday, 26 June 2026 01:15:23 Pacific Daylight Time Rune Lund Olesen wrote:

2. In generic code, while you can actually bitshift a std::byte, it eg. acts
as an enumeration type and returns false with std::is_integral,
std::is_fundamental, and so on - highlighting a few issues with using it
with generic code 3. The idea to have a type to correctly represent "raw
data" is good - it is the design or implementation if you will, that is
lacking, and it should interop easier with other things (like conversions)
and work better in generic code - right now it it way too restrictive and
cumbersome, to the point it is prohibiting adoption.

I believe the main roadblock to adoption is that unsigned char is still there
and *is* the byte type.

The main problem with unsigned char is that it's also uint8_t, and it's
also char8_t.

No, char8_t is a distinct type, just like char16_t and char32_t.

Hmmm, it seems C++ doesn't have this problem; we have it in C:

	$ grepc char8_t /usr/include/
	/usr/include/uchar.h:typedef unsigned char char8_t;

char8_t was added to C via N2653 (char8_t: A type for UTF-8 characters and strings). The paper contains a section discussing whether to add char8_t as a typedef name vs a new integer type. The last paragraph in that section is:

 Introduction of a new char8_t integer type without a corresponding change to make wchar_t, char16_t, and char32_t distinct integer types would be inconsistent and surprising. While the author sees potential use for distinct types as shown above, such a change of direction should be pursued via a separate proposal. Should WG14 indicate support for such direction when reviewing this proposal, the author will submit a separate proposal. In the meantime, this proposal advocates for only a new char8_t typedef name in order to maintain consistency with the existing character types. 

When I presented the paper to WG14, this was discussed, but none of the participating WG14 members encouraged pursuing a change to make these distinct types.

Tom.

The problem about uint8_t is still there, though.


Cheers,
Alex

 That makes it rather difficult to distinguish UTF-8
strings from short integers, and from raw bytes.