Date: Thu, 25 Jun 2026 14:36:25 +0000
My first suggestion is, don’t do byte2. Just eliminate the current std::byte, make it a fundamental for real (not a fake one), I have an inkling nobody will care for this one.
But my second observation is:
I also used to define my own byte_t, doublet_t, quadlet_t, octlet_t.
Then I realized just use uint8_t as your byte_t, and then I stopped having a pain in the ass of having to maintain those types.
But I can hear you complaining, “but then your byte can do addition, and multiplication, those are not things that a byte shouldn’t be able to do”, which is perfectly understandable.
But then I say “Says who? Why do you care that you can do addition with your bytes, that it is so big of a problem that you need to maintain support for a whole new set of types just to stop it?”
Is it worth the effort to maintain a new type (and all of the baggage that comes with it, formatting, casting rules, etc), just so that you cannot do something that has very little consequence? (I assure you it is very hard to write byte addition by mistake)
In any case I kind of like to be able to perform arithmetic on my “bytes”, as often a bag of bytes starts and ends their life as some other data type, and often just makes it easier if I can do arithmetic.
I can hear “but it is technically incorrect!”. So? Is it worth the effort?
From: Std-Proposals <std-proposals-bounces_at_[hidden]> On Behalf Of Rune Lund Olesen via Std-Proposals
Sent: Thursday, June 25, 2026 15:34
To: std-proposals_at_[hidden]cpp.org
Cc: Rune Lund Olesen <rune.olesen_at_[hidden]>
Subject: [std-proposals] A better std::byte type
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...
Kind regards
Rune Lund Olesen
(writing c++ for ~20 years)
Senior Engineer
Gatehouse SatCom
Denmark (sorry for possible quickly written english)
namespace std
{
struct byte2 {
byte2(){};
byte2(uint8_t value) : value{value} {
}
explicit operator uint8_t() const {
return value;
}
// more usefull functions, overloads, whatever
uint8_t value{};
};
template<>
struct is_fundamental<std::byte2> : true_type {
};
template<>
struct is_unsigned<std::byte2> : true_type {
};
//more type traits
}
static_assert(std::is_fundamental_v<std::byte2>);
static_assert(std::is_unsigned_v<std::byte2>);
void f() {
std::vector<std::byte2> mybytes{};
std::vector<uint8_t> mybytes_uint {mybytes.begin(), mybytes.end()};
std::byte2 b;
uint8_t f;
//f = f + b; //will give compiler error
}
But my second observation is:
I also used to define my own byte_t, doublet_t, quadlet_t, octlet_t.
Then I realized just use uint8_t as your byte_t, and then I stopped having a pain in the ass of having to maintain those types.
But I can hear you complaining, “but then your byte can do addition, and multiplication, those are not things that a byte shouldn’t be able to do”, which is perfectly understandable.
But then I say “Says who? Why do you care that you can do addition with your bytes, that it is so big of a problem that you need to maintain support for a whole new set of types just to stop it?”
Is it worth the effort to maintain a new type (and all of the baggage that comes with it, formatting, casting rules, etc), just so that you cannot do something that has very little consequence? (I assure you it is very hard to write byte addition by mistake)
In any case I kind of like to be able to perform arithmetic on my “bytes”, as often a bag of bytes starts and ends their life as some other data type, and often just makes it easier if I can do arithmetic.
I can hear “but it is technically incorrect!”. So? Is it worth the effort?
From: Std-Proposals <std-proposals-bounces_at_[hidden]> On Behalf Of Rune Lund Olesen via Std-Proposals
Sent: Thursday, June 25, 2026 15:34
To: std-proposals_at_[hidden]cpp.org
Cc: Rune Lund Olesen <rune.olesen_at_[hidden]>
Subject: [std-proposals] A better std::byte type
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...
Kind regards
Rune Lund Olesen
(writing c++ for ~20 years)
Senior Engineer
Gatehouse SatCom
Denmark (sorry for possible quickly written english)
namespace std
{
struct byte2 {
byte2(){};
byte2(uint8_t value) : value{value} {
}
explicit operator uint8_t() const {
return value;
}
// more usefull functions, overloads, whatever
uint8_t value{};
};
template<>
struct is_fundamental<std::byte2> : true_type {
};
template<>
struct is_unsigned<std::byte2> : true_type {
};
//more type traits
}
static_assert(std::is_fundamental_v<std::byte2>);
static_assert(std::is_unsigned_v<std::byte2>);
void f() {
std::vector<std::byte2> mybytes{};
std::vector<uint8_t> mybytes_uint {mybytes.begin(), mybytes.end()};
std::byte2 b;
uint8_t f;
//f = f + b; //will give compiler error
}
Received on 2026-06-25 14:36:30
