Hi Tom,

On 2026-06-28T21:02:52-0400, Tom Honermann wrote:
> 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.

I like that it was made a typedef. It's more consistent with the
language. I think it's the byte type that should be a different type.
That's the actual problem. If I had a time machine, I'd go back and
add a _Byte type when void* was added.

Confusing a string with a number is unlikely. Confusing a byte with
a number or a byte with a string is the likely thing.


Have a lovely day!
Alex

>
> 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.
> >

-- 
<https://www.alejandro-colomar.es>