Should keccak::f1600 take a &mut [u8; 200] rather than a &mut [u64; 25]?

[hdevalence]

I think it would be better if the keccak::f1600 function explicitly took a byte array, rather than taking an array of 64-bit words.

The reason is that this allows the keccak crate to provide endianness handling internally, rather than forcing every client crate to handle it themselves (or just leaves them to not handle it at all).

[newpavlov]

I think it will have a worse performance, especially on big-endian machines, as you'll have to do byte swapping twice per function call (on read and write). For little-endian machines compiler may optimize redundant temporary array and read/writes into it, but I wouldn't bet on it.

[hdevalence]

On little-endian machines, you can use a pointer cast to convert a &mut [u8; 200] into a &mut [u64; 25] for free. You may have to byte-swap on big-endian machines, but clients will have to do that anyways if they want to access the bytes of the sponge data.

I guess the point is not really about the performance, but about whose responsibility it is to handle endianness. Maybe the crate could provide an f1600_bytes function that took a &mut [u8; 200] and did a byte-swap on big-endian machines?