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

I don't really see the problem. You'd need to provide a concrete example.


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

Bit-shifting arguably should have never been added to std::byte (nor any
other operators, but shifting is particularly bad). The rationale for not
providing arithmetic operators like multiplication is that it's just meant
to be a "bag of bits", but left-shifting is defined as multiplying with a
power of two, so it makes very little sense that you can multiply using << 1
but not using * 2.

My main issue with std::byte ergonomics is the initialization. You cannot
do things like

constexpr std::byte png_magic_bytes[] {
    0x89, 0x50, 0x4E, 0x47, 0x0D, 0x0A, 0x1A, 0x0A,
};

... to help with checking whether some byte buffer is a PNG file.

You also can't use std::byte for anything related to I/O. It won't work
with std::fwrite, std::ostream, etc. forcing you to use reinterpret_cast
all over the place if you want to do anything useful with it.

Some people may argue that it's not intended to be used as an "I/O byte"
but only to introspect C++ objects, but then the motivation for this type
is so microscopic that it should have never been added to C++. The tiny
amount of C++ code that deals with inspecting bytes of an object can just
use unsigned char.