Endianness, API Design, and Polymorphism in Rust

Somehow this is connected to https://news.ycombinator.com/item?id=29367649 I had never thought of this until that thread, but our writing of numbers comes from Arabic, and Arabic is written from right to left. And from our western perspective numbers in Arabic being written left to right is backwards. But in fact, it's us who are backwards: Arabic is written from right to left, and numbers too... from the least significant to the most significant. But we took the numbers from Arabic and kept their left-to-right order and now write them from MSD to LSD...

About this section:

> Unfortunately, as the ??? shows, the different output arrays have different lengths – a u16 would be 2 bytes and a u64 8 bytes – and so the Rust trait system at the time of this writing is (to my knowledge) not powerful enough to represent this trait as is.

It seems to me that this is possible using const generics. If you define your EndianBytes like this:

    trait EndianBytes<const N: usize> {
        fn be_bytes(self) -> [u8; N];
        fn le_bytes(self) -> [u8; N];
    }

Then provide a concrete length with each impl:

    impl EndianBytes<4> for u32 {
        fn be_bytes(self) -> [u8; 4] {
            self.to_be_bytes()
        }
        fn le_bytes(self) -> [u8; 4] {
            self.to_le_bytes()
        }
    }

(I've renamed their methods to avoid conflicting with u32::to_be_bytes to make it easier to read)

Then that allows you to use the EndianBytes type as long as you remain generic over both the value type and its length:

    fn write<T: EndianBytes<N>, const N: usize>(val: T) {
        println!("{:?}", val.be_bytes());
    }

    fn main() {
        write(0x1234u16);
        write(0x12345678u32);
    }

This code (plus an impl for EndianBytes<2> for u16) works for me on 1.51 stable.

EDIT: I thought about doing this with an associated constant, ie:

    trait EndianBytes {
        const LENGTH: usize;
        fn be_bytes(self) -> [u8; Self::LENGTH];
        fn le_bytes(self) -> [u8; Self::LENGTH];
    }

However it turns out that this kind of usage is not quite supported yet: https://github.com/rust-lang/rust/issues/60551

While I know the performance cost is relatively minimal, it's interesting to think about the collective cycles wasted byte swapping back/forth to big endian for the network...now that little-endian machines dominate the landscape.

The detour through "struct BigEndian" etc. is an artifact of a built-in limitation on expressiveness in Rust that I gather is soon to be remedied, at least in part, once proper support ("const generics", a weird name; in C++ that is "non-type template parameters") is considered stable enough to commit to.