[std] mem.readInt is confusing and hostile to optimization

[thejoshwolfe]

The loop bounds are determined from the runtime-known bytes.len instead of the comptime-known @sizeOf(T). This prevents/discourages the compiler from unrolling the loop. For native endian reads, mem.readInt should optimize to a single (unaligned) load instruction, but this seems unlikely with the current API.

Why is there an API for reading an int from too few bytes? When would you want that? This was surprising to me when I read what readInt would do.

Proposal: Move the current API to something that indicates how weird it is, like mem.readPartialInt. I've already pushed optimizable implementations of readIntLE and readIntBE which you can use if you know at comptime which one you want. Add a mem.readIntWithEndian that takes a runtime-known endian and calls one of readIntLE or readIntBE. The long name is to discourage you from calling it unless you really only know the endian at runtime, which seems like a rare usecase.

[andrewrk]

Why is there an API for reading an int from too few bytes?

The docs are:

/// Reads an integer from memory with size equal to bytes.len.
/// T specifies the return type, which must be large enough to store
/// the result.

Where are you getting this idea from?

[thejoshwolfe]

Why is there an API for reading an int from too few bytes?

https://github.com/zig-lang/zig/blob/5786df933d37d52d57fef9c28acb9c2c23128d31/std/mem.zig#L387-L396

[andrewrk]

Reads an integer from memory with size equal to bytes.len.

The above example has buf.len == 4, therefore it reads a 32-bit integer.

/// T specifies the return type, which must be large enough to store
/// the result.

The above example passes u64 as T, and therefore the return type is u64.

64 bits >= 32 bits. Where does "too few bytes" come in?

[andrewrk]

https://github.com/zig-lang/zig/blob/5786df933d37d52d57fef9c28acb9c2c23128d31/std/debug.zig#L306

Here's the usage. Feel free to refactor this as you see fit if you come up with a better API.