Any design for this issue will interact with other issues tracked by #885; make sure to read that issue when tackling this one.

All of the types in the byteorder module have no alignment requirement since they were designed for packet parsing, where values may appear at any alignment. For some applications, it's still useful to support byte-order conversion, but in a context in which alignment is guaranteed. In these cases, being able to guarantee alignment can result in faster and smaller code on some platforms. We should consider adding types which are like the existing ones, but have the same alignment as their native equivalents. Alternatively, we could modify the existing types to support both alignment modes.

Another thing to consider is that, currently, the byteorder module conflates alignment concerns and byteorder concerns. These happen to often be relevant at the same time (e.g. in the context of packet parsing), but they are conceptually distinct. Now that we have the Unalign type, the unaligned property is arguably unnecessary - we could just provide a) byte order-aware types, b) the Unalign type and, perhaps, c) convenience type aliases for unaligned byte order-aware types (e.g., type Foo<O> = Unalign<U32<O>>). We would need to think about how to avoid the combinatorial explosion of the following dimensions:

• The type itself (U8, U16, etc)
• Byte order (big endian, little endian, and maybe also network endian and native endian if we're concerned with aliases)
• Alignment ("normal" vs wrapped in Unalign)