Is it possible to backport std::byte to C++14

std::byte is defined in C++17 as:

enum class byte : unsigned char {};

I'm currently stuck at using C++14, and I wonder if I add the same definition in C++14 (in some non-std namespace, along with the operator overloads etc.), will this new type get the same aliasing "free-pass" as an unsigned char or I setting myself up for undefined behavior due to violating the strict aliasing rule?

It seems to work, but I'm wondering if I instead should go with using byte = unsigned char; which sadly causes other complications (for instance then I can't make a difference between a byte and uint8_t).

No, it isn't possible. The aliasing exception is specific only to char, unsigned char and std::byte. You can't define a type in standard C++ to also gain their "superpower".

There may be compiler-specific attributes that can give a type declared with

enum class byte : unsigned char {};

equivalent aliasing exceptions, although aliasing isn't the only exceptional behavior either.

Technically std::byte and unsigned char are also specific exceptions in the core language that are able to provide storage for other objects and the only types that can cause implicit creation of objects when the lifetime of an array of their type starts. Other types can't do either. However, on the usual C++ implementations that part is probably not really all that relevant in practice.

std::byte and unsigned char (and potentially char) are also the only types for which it is sometimes allowed to operate on indeterminate values in some very specific circumstances. But again, on usual C++ implementations that probably isn't going to be a practical problem.

There is also an exception for array-new expressions that guarantees specifically only for char, unsigned char and std::byte that there is no offset between the beginning of the allocation and the beginning of the array. Again though, in practice implementations will probably extend this exception to all trivial types.

The C++ Standard does not impose any normative requirements upon programs, despite the phraseology used in much of it (From section 4.1.1: Implementation compliance: General):

> Although this document states only requirements on C++ implementations, those requirements are often easier to understand if they are phrased as requirements on programs, parts of programs, or execution of programs. Such requirements have the following meaning:
>
> ... If a program contains a violation of a rule for which no diagnostic is required, this document places no requirement on implementations with respect to that program.

Although C14 does not require that implementations provide a practical means of supporting the described functionality, nearly all implementations can be configured to extend the semantics of the language to support such functionality in consistent fashion. Clang and gcc both use the -fno-strict-aliasing flag for that purpose. Unless one has a particular need to use a compiler which does not support such extensions, using such extensions when performing tasks that benefit them is apt to be safer than compiling without them even if one jumps through hoops to ensure that any bug-free compilers would be required to process one's code correctly.