C++ Logo

std-proposals

Advanced search

Re: [std-proposals] A better std::byte type

From: Alejandro Colomar <une+cxx_std-proposals_at_[hidden]>
Date: Thu, 25 Jun 2026 17:28:20 +0200
Hi,

On 2026-06-25T18:05:25+0300, Andrey Semashev via Std-Proposals wrote:
> On 25 Jun 2026 16:33, Rune Lund Olesen via Std-Proposals wrote:
> > Hello All,
> >
> > The current std::byte has some deep issues in that it is too opaque to
> > the point it is flawed by design.
> > (we know it is in reality a scoped enum).
> > Especially this comes up in generic code where it is cumbersome to add
> > specializations because it is not a fundamental type.
> >
> > A "better" way would be a real fundamental type or struct that mimicks it...
> >
> > Overall it should at least behave like a fundamental uint8_t/unsigned
> > char in most respects
> > and be easy to convert to/from...
> > except ofc. it shouldn't be an arithmetic type and it shouldn't be
> > treated like a textual "char" as we know.
> >
> > See below for a quick draft up...
>
> The world has more or less settled on unsigned char/uint8_t as the type
> for raw bytes. std::byte was a failure exactly because it is
> sufficiently different and requires casts all over the place, and
> because it is not a fundamental type (i.e. requires a header include).
> Introducing a built-in type solves the latter but not the former.

We discussed last year in WG14 the possibility of a new _Byte type.
Conversations stalled, but we agreed that if it were to be added, it
should have the implicit conversion properties of void*.

_Byte* would have all of the special properties of void* and
unsigned char*.


Have a lovely day!
Alex

> IMHO, just give up and stop pretending that bytes aren't uint8_t.
> Restricting arithmetics on bytes isn't much of a benefit anyway,
> especially when you want to do arithmetics (e.g. when you're parsing
> from raw bytes).
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals

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

Received on 2026-06-25 15:28:32