I do think that the only approach that manifests benefit of uintptr_t != size_t is to have usize == size_t and an error on such platforms for casting pointers to usize.
The goal of @InfernoDeity is that on w65, memory locations are 32 bit, but object sizes and offsets are 16 bit. Sure, Rust could target such a platform if usize == uintptr_t, but usize is the indexing type in Rust, which means that the actual w65 benefit of not making the two types the same width the same size is completely lost in Rust, and they might as well be the same size.
That's the conflict here: Rust's core library design assumes that usize is sufficient both for size_t and uintptr_t.
Our one out (imho) is that while ptr as usize is fairly common, it should be niche. Or IOW, it's common because widely used libraries do it, not because everyone does it.
So imho the best way forward to optionally separate uintptr_t from size_t in Rust is
- Admit that due to the existing practice and design of Rust, such platforms are considered "exotic" and will often not "just work" with any library doing pointer tricks,
- Do our best to make such issues caught at compile time, thus
- Declare that
usizeissize_t, - Introduce a new type (e.g.
uaddr) which is declared to beuintptr_t, - When
ascasting from pointer tousizeon such platforms, emit an error-by-default lint, - Provide the lint as allow-by-default on other platforms for the purpose of portability,
- Declare that, at least for the time being,
stdassumes a standard platform whereusizeanduaddrare equivalent, and - Audit
corefor any library assumptions thatusizeisuaddr, and either fix them (if internal) or somehow make them loudly complain on platforms where this isn't the case.
The reasoning behind taking this angle is that while ptr as usize is required and endorsed by the language today, the use of usize as the indexing type is much more widespread.