It is an interesting, awkward edge case. But the utility of a u64 length might be rarer than you think. `Range<usize>` will be more common for wrangling memory sizes, and will handle 64-bit sizes on 64-bit targets - so the utility of Range<u64> would mainly be for larger-than-address-space sizes, which probably means falliable I/O calls.
I've been considering upstreaming a trait into the read_write_at crate to provide std::io::Result<u64> lengths for Mutex<impl std::io::Seek> / std::fs::File (on platforms where length is available without mutating seek position - such as on windows via file.metadata().map(|m| m.file_size()) per:)
There's a whole slew of u64 offsets and sizes... the occasional subtraction to calculate a maybe-larger-than-memory size doesn't seem like that big a deal. Occasionally there are methods implemented for it - typically named "file_size()" instead of "len()" though.
I've been considering upstreaming a trait into the read_write_at crate to provide std::io::Result<u64> lengths for Mutex<impl std::io::Seek> / std::fs::File (on platforms where length is available without mutating seek position - such as on windows via file.metadata().map(|m| m.file_size()) per:)
https://doc.rust-lang.org/std/fs/struct.File.html#method.met...
https://doc.rust-lang.org/std/os/windows/fs/trait.MetadataEx...
Context: multithreaded reads of zip archives & https://github.com/vi/read_write_at/issues/1 & https://github.com/MaulingMonkey/vfs-zip
There's a whole slew of u64 offsets and sizes... the occasional subtraction to calculate a maybe-larger-than-memory size doesn't seem like that big a deal. Occasionally there are methods implemented for it - typically named "file_size()" instead of "len()" though.