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

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>