>>106223380
>Here it's obvious but with things like "from_utf8" you never know what's going on.
>Converts a slice of bytes to a string slice
It's pretty straightforward. It just takes some arbitrary bytes slice and reinterprets them into str if they are valid utf8. str is guaranteed utf-8 encoded string so that's why a byte slice [u8] and str is not the same thing.
>I agree that in theory the compiler could do what it wants with a fixed size array and transform the callee and caller to use machine words for short arrays, but if it doesn not I don't see how a pointer or reference could be avoided.
[u8; 4] is an array, not a slice or string or pointer. It's just 4 bytes by value, by definition. Just like a tuple (u8, u8, u8, u8) or struct { byte1: u8, byte2: u8, byte3: u8, byte4: u8 }, except they are guaranteed to be places one after another in memory and allows for numeric indexing. A callee receives entire array by value, as in memcpy'd not by reference. Notice no dereference in pic related.
>Not necessarily, you could remove the bounds check inside and instead make the caller do it, if there is a need. The caller may already know that the output buffer is large enough or that the pointer into the input buffer is far from the end.
All of this irrelevant if you just deal with bytes by value
>Of course, and yes you could load bytes individually and modify the endianness, but it's also possible to load 32 or 64 bits directly and then change the endianness, it will likely be faster. So that's not a necessity but it can happen and it can be desirable.
Yes, and that's what you archive when you do some_byte_iter.array_chunks().map(u32::from_be_bytes). No need to wrestle around with pointers, alignment, etc.