I’ve long thought that mut is misnamed or the name is at least misleading. It is about the distinction between a shared and exclusive reference to something. A similar example where I’ve seen this cause confusion is that atomics don’t need a mut reference for modification, since the whole point of atomics is allowing multiple shared references to safely perform mutations.

The title is exaggerated. These I/O abstractions are stateful, and mutation of the state requires &mut. The fact that these traits aren’t ideal for a special case of in-memory random access doesn’t make them dangerous.

I wonder if this could be avoided by using a zip::ZipArchive<Cursor<&'data [u8]>>. This ZipArchive can be cheaply clone()ed.

You could do the same thing with a file by using zip::ZipArchive<MyFileWrapper>. Where MyFileWrapper implements Read + Seek by containing an Arc<std::fs::File> and a u64 offset, and then implementing these traits by using the read_at function on the file (which corresponds to the pread syscall) to let multiple users read at different positions.

In the second paragraph, I’m already realizing the solution: Read + Seek + Clone. If something is random access, the Read+Seek object is a position handle, not the sole access pathway to the data (which Read must accommodate).

Use the flamebait title, you cowards.