On 6/26/26 10:34 AM, Alejandro Colomar via Std-Proposals wrote:
> 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_at_[hidden]> 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 astd::byte, it eg. acts
>>>>> as an enumeration type and returns false withstd::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)
<https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2653.htm>. The paper
contains a section discussing whether to add char8_t as a typedef name
vs a new integer type
<https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2653.htm#do_char8_t_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.
>