We already have functions very much like this in encoding/binary.

The functions in encoding/binary are more expensive than these.

Using encoding/binary forces you to specify the desired endianness, which seems desirable.

Using native host endianness is a path to trouble in the long run. I don't think we should encourage it.

Fair point. Can we add functions that avoid slicing, even when specifying endianness? Slicing introduces overhead when the goal is to convert a single word.

Are the encoding/binary functions inlinable? If they are, the slicing costs should disappear in practice.

Do you have a benchmark comparing your suggested functions and the encoding/binary functions?

If encoding/binary is too expensive, we should optimize it, not jump immediately to adding new API. That starts with a benchmark demonstrating the problem.

This code:

func f(x [8]byte) uint64 {
     return binary.LittleEndian.Uint64(x[:])
}

already compiles to just 2 instructions (2 MOVQ, from the input stack slot to a register, and from the register to the output stack slot).

Ok, thanks. Given that the encoding/binary functions are being inlined, please feel free to close this, or lmk and I'll close it.