| According to the naming, yes indeed 1 byte has endianness. I know that isn't the intention. It isn't unheard of for 1 byte to have endianness. To be specific, we can call it "bit endianness". It matters when serializing bits to go over a wire, such as when bit-banging I2C or SPI. An array doesn't normally have endianness either. I guess you could have a programming language that does the indexing backwards, with 0 at the end of the array. I've never heard of such a thing existing. Compare this with a endianness functions typically used in C. We get ntohl for example. The size is specified by the "l", the argument is of type "long", and the return value is of type "long". No bytes are involved in that interface. Compare with what the Linux kernel uses. Again, no bytes are anywhere to be seen. Functions like cpu_to_le32 take and return 32-bit values. It looks like Rust is doing things Python-style, which is a scary thought. Instead of providing distinct ways to change endianness and to interpret data as integers, the functionality is crammed into one interface. |
Except it's not. These specific methods aren't some grand interface to change endianness. These are convenience routines for converting between bytes and integers, which is a not altogether uncommon thing to do. I certainly do it a lot.
The existence of these byte-to-integer conversion methods does not imply the non-existence of other methods to convert endianness within integers. Indeed, those methods have existed since Rust 1.0: `swap_bytes`, `from_be`, `from_le`, `to_be`, and `to_le` are all methods defined on {integer type} that return {integer type}.