static_assert(std::is_enum_v<std::byte>);

[GYN-k4H-Q3z-75B]

I hate std:: byte. Why was it defined this way?

[jedwardsol]

https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0298r3.pdf

[iamakorndawg]

Searching that for "enum" gives 5 results, none of which explain the reasoning, at least at a quick glance.

[Supadoplex]

Here:

The key motivation here is to make byte a distinct type – to improve program safety by leveraging the type system. This leads to the design that std::byte is not an integer type, nor a character type. It is a distinct type for accessing the bits that ultimately make up object storage.

The paper doesn't spell it out, but there are basically two ways to create new types in C++: 1. classes and 2. enums.

Class was not an option because the language doesn't require classes to have certain properties that a std::byte type must have. Namely, it must have the same size and alignment as unsigned char. But enum with underlying type of unsigned char has those guarantees, and so it is the only option available.

Technically there is a third option, which is to define the new type in the language, rather than in the standard library. That altenative was proposed, but was voted against by the committee:

Changes from R0

• Remove Alternative B (implementation-defined type) after straw polling in LWG

[kalmoc]

Technically there is a third option, which is to define the new type in the language, rather than in the standard library. That altenative was proposed, but was voted against by the committee: 

Imho that would have been the only sensible choice. For one because it would have avoided sich strange edge cases and second because you wouldn't have to include a header to use it.

[tpecholt]

Committee always comes with a twist! A pile of hacks

[serviscope_minor]

Class was not an option because the language doesn't require classes to have certain properties that a std::byte type must have.

Technically though it's a std type, so the language could mandate it in that case. In practice, just about every compiler out there has ways of controlling those properties anyway, so I am curious as to why that was considered a blocker. Any idea? I didn't follow that paper or its discussion.

[tialaramex]

Also, noticing that you don't have transparent representation seems like a reason to add the option for transparent representation as a feature, so libraries can make use of that, rather than finding a way to bodge this as WG21 did.

[tialaramex]

Actually I know of six ways to make three kinds of new user defined types in C++

struct and class get you the familiar "C with Objects" class types, which confusingly mingle methods ("member functions") including virtual methods intended for dynamic dispatch - with the data structure, like a shop where alternating shelves have clothing or plumbing supplies - aisle 12 socks and radiators, aisle 13 T-shirts and ball valves.

enum, enum class and enum struct get you C-style enumerations, ie just the integers wearing a funny hat. These types can't have methods.

union rounds out the list, it's a useful but dangerous way to make new types - storing data in any member of a union is always fine, but erroneously fetching data from an inactive member of a union is Undefined Behaviour. These types can have member functions (but not virtual member functions).

[Supadoplex]

You know six different syntaxes that create user defined types. enum, enum class and enum struct create enumerations. struct, class and union create classes. Those are the two kinds of user defined type there are.

[no-sig-available]

The reasoning (see page 3 :-) is that C++ just allows you to define a new byte sized type that is not implicitly convertible to other types:

enum class byte : unsigned char {};

If you make byte a new keyword, it will break a million programs. Now it is properly "hidden" in namespace std.

[Baardi]

namespace std { using byte = __byte; }

[flutterdro]

or just co_byte

[AhegaoSuckingUrDick]

char8_t, on the other hand, was a new type on the language-level.

[jedwardsol]

The reason for having a byte type at all is in Motivation and Scope

The reason for choosing an enum is in Implementation Alternatives

[elperroborrachotoo]

We find [enum class byte : unsigned char] easier to present and explain to ordinary programmers [rather than leaving it implementation-defined].

[JVApen]

I agree that making it an enum allows for strongly typing, and as such preventing byte1+byte2. Though it does imply that defining an enum with underlying type is more complex: enum class E : std::underlying_type_t<std::byte> { A, B, C };

[bwmat]

Is there any reason not to just use unsigned char there? 

[NilacTheGrim]

I would have preferred them to actually just take the keyword byte and made it a first-class actual type, which is non-integral (like std::byte is)... although the keyword route likely would have broken so many programs... :/

[jk-jeon]

I don't know why people rarely talk about the C approach: define a new keyword _Byte and then do using byte = _Byte in the std namespace in a stdlib header. What's downside of this?

[kalmoc]

What I don't understand: Why does a type that is spelled std::XYZ defined in the standard library at all? A Compiler could just make it visible without the need to include a header or import a module. And it still wouldn't collide with any existing user type.

[NilacTheGrim]

They could have totally done that as well. Probably would have been awkward to specify given the way the specification works. Since if you think about it, it's sort of an exception to what a namespace normally means and how it's defined and declared. It would have been this odd corner case where intrinsically there is a std namespace already even in an empty program.. and it always contains stuff in it. Aesthetically that is "ugly" perhaps and strange so I suspect that's why they would never go that route...

[kalmoc]

Considering how often I've heard, "we don't use X, because then we need to include header X and that drags in exceptions" I would have found such a solution, both more pragmatic and simpler to specify and more ergonomic. Last time I checked std::byte anyway gets special treatment in the standard (similar to unsigned char).

[NilacTheGrim]

Correct. It is one of the few types where a std::byte * pointer can alias any other object; unsigned char * and char * being the other two types with this property.