Making everything you use there bytearrays and doing explicit swapping read/write operations to it is certainly an option, but it's pretty clunky.
Probably some proc macro derive solution are there, or at least it can be implemented. You don't have to write manually.
So, I hadn't spotted zerocopy until it was mentioned above. It appears to do basically the right thing in terms of having type-segregated specific order. network-endian and endian-type seem to do something similar. (endian_trait by contrast seems to positively encourage a dangerous approach)
I still thing the explicit gets/sets are clunky though. I can't really envisage how a proc macro would help with that - what did you have in mind?
#repr(bigendian) and #repr(littleendian) be attachable to any of the fixed-width built-in integer types. They'd only be valid where #repr(C) or #repr(packed) is already in effect.
I feel this is an arbitrary attribute. Attributes don't play well with generics too.
If we specify some aspects of memory layout with #repr(C) or #repr(packed), why is it arbitrary to specify integer encoding as well? They're both about how you translate the abstract concept of the type to specific bytes at specific offsets.
I don't really see how generics get involved, more or less by definition we're talking concrete types with concrete memory layouts.
An alternative to attribute is auto-trait. Or a regular trait with your own
derivemacros. What is the reason to prefer attributes over traits?
Again, I can't really envisage how a trait would help you here, automatically derived or otherwise. It's not that you want to do anything extra with the value - you just want it to behave like an integer - but you want the in-memory representation to be fixed.
You certainly can do this safely with wrapper types (like the crates mentioned above), but why would I want to use that in addition to #repr(C), when they're both about in-memory representation of the data.