Using pointer-sized sizes for in-memory collections and slices is no mistake, and every single Rust API involving file offsets or sizes in the Rust stdlib that I'm aware of uses u64 or i64, not pointer sized stuff. Perhaps you didn't mean to imply otherwise, but you do.

That iterators and ranges have this 1% edge case where you'll need to roll your own trait if you want "(0u64..1).len()" to compile because ExactSizedIterator was designed for the 99% case of in-memory collections, could be argued as a design mistake - or could be argued as a reasonable avoidance of overcomplication in std in favor of allowing the end users who encounter that edge case to solve the problem how they please, if it is indeed a problem for them.

    trait Len64 {
        fn len(&self) -> u64;
    }
    impl Len64 for std::ops::Range<u64> {
        fn len(&self) -> u64 { self.end - self.start }
    }
    fn main() {
        println!("{}", (0u32..!0).len());
        println!("{}", (0u64..!0).len());
    }

https://play.rust-lang.org/?version=stable&mode=debug&editio...

    4294967295
    18446744073709551615

Meanwhile, I'm still inheriting C/C++ codebases using APIs that know they're dealing with files and still use pointer-sized integers. In their defense, the system APIs they use often predate widespread 64-bit integer support in 32-bit C compilers (I'm looking at you, fseek/ftell). Less in their defense, the wrappers around said system APIs often postdate the very same, and postdate a slew of alternative APIs that don't even need 64-bit integer support.