My two pennies worth...

C++ does not have a good "raw data" type that represents underlying
memory storage, and nothing else. It has a jumble of types that each do
other things as well, or have limitations for convenient usage as raw
data. There is a lot that is bad in all of this. But it cannot be
fixed. The "best" you can do is add more to the jumble, as was done
with std::byte. The time to fix it would have been 50 years ago when
Ritchie thought it would be a good idea if a type "char" represented
character data, and raw memory bytes, and was a small integer type.

Unless your new "byte" type stops "unsigned char" being a byte type,
stops "void *" being a generic pointer to data, is the only type with
"aliasing superpowers", and is the type used in "memcpy" and everything
else that today uses "void *", then it would only add to the mess rather
than fixing it. And of course backwards compatibility requirements
ensure that none of those changes could possibly happen.

One thing that I think is missing, that /could/ be fixed, is raw data
types that are bigger than a byte and which have "aliasing superpowers"
to access underlying data representations. This could be achieved by
standardising gcc's "may_alias" type attribute - then such types could
be "[[may_alias]] uint32_t", or as an enum class or struct if preferred.

I agree that std::byte would have (IMHO) been better without shifts or
other bitwise operations, but it is hard to remove features and I am not
convinced that adding more conversions would help.

David



On 26/06/2026 10:15, Rune Lund Olesen via Std-Proposals wrote:
> Thank you all for the feedback.
>
> To clarify a few points:
>
> 1. The Idea here is more to "fix" current std::byte than add new one (I
> wrote byte2 to not clash with current std::byte)
> 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.
>
> Alex, it is good to hear discussions have already been taking place.
>
> Have a lovely evening
>
> Rune Lund Olesen
>
>
>
>
> On Fri, Jun 26, 2026 at 12:05 AM Thiago Macieira via Std-Proposals <std-
> proposals_at_[hidden] <mailto:std-proposals_at_[hidden]>> wrote:
>
> On Thursday, 25 June 2026 08:05:25 Pacific Daylight Time Andrey
> Semashev via
> Std-Proposals wrote:
> > The world has more or less settled on unsigned char/uint8_t as
> the type
> > for raw bytes
>
> unsigned char is *by definition* the byte type. uint8_t happens to
> also be the
> byte type[1] if it exists. std::byte is just an enum whose
> underlying type is
> the byte type.
>
> [1] strictly speaking, it could be another integer whose same size
> is the byte
> type, but in all implementations it's just a typedef to it.
>
> --
> Thiago Macieira - thiago (AT) macieira.info <http://macieira.info> -
> thiago (AT) kde.org <http://kde.org>
> Principal Engineer - Intel Data Center - Platform & Sys. Eng.
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden] <mailto:Std-Proposals_at_[hidden]>
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
> <https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals>
>
>