[kevindqc]

I don't understand? Isn't that to convert from an array of bytes to a native type? So those bytes need to be in a specific order (in this case, native endianness)?

Do you mean someone could get confused because they think 1 byte has endianness? Well then maybe they shouldn't touch these functions since they don't understand what is endianness.

It's weird that they have these methods on a u8 though. Probably just comes automatically because it's an integer type so they prefer to have a consistent API?

It seems to come from a macro used to define those primitive int types: https://doc.rust-lang.org/stable/src/core/num/mod.rs.html#38...

[tropo]

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.

[burntsushi]

> 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}.

[shaklee3]

You're confusing bit ordering and endianess. There are many microcontrollers that will change the bit ordering on i2c and spi buses to accommodate various devices, but that's not endianess.

[tropo]

Bit ordering and byte ordering are both endianness. Word ordering is also endianness, as is nibble ordering. It's all endianness.

The fact that we typically refer to byte ordering doesn't mean the others are not also endianness.