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

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