The discussions in RFC PR 544 leads me to think that, if we cannot find a single pair of names for pointer-sized integer types that can satisfy most people, would having two pairs for different use cases be a good solution?
The core problem with the proposed names is that, pointer-sized integers have many different use cases in Rust, but barring one (
imem/umem, and the variant
intm/uintm), all candidate names are either too vague, or favouring specific use cases over others, and/or looking like some C/C++ types that may tempt people to make incorrect assumptions. And
imem/umem are not liked enough either.
So maybe we can take a page out of standard C/C++'s book, and define both
idiff/usize, and use them in different use cases?
iptr/uptr will be used in cases where
intptr_t/uintptr_t get used in C/C++: for storing casted pointer values.
idiff/usize will be used like
ptrdiff_t/size_t: pointer/index offsets and container sizes/indices, respectively.
iptr/uptr will be the underlying types, and
usize will either be their aliases, or considered different types (“newtypes”) entirely. (In the latter case, the fact that
usize are pointer-sized may or may not be considered an implementation detail.)
This setup will make Rust’s integer types align well with standard C’s, which is a plus from the familarity point of view. Still, the underlying sementics is not completely the same, and having two pairs of types that share the same underlying representation may be confusing, but these drawbacks are smaller in my eyes than using
uptr for container sizes or
usize for storing pointer values.
(I personally still prefer the
imem/umem solution to this, but I can see why many others don’t agree with me. This solution is my second favourite now.)
iptr/uptr/idiff/usize a good idea or will it create much unnecessary confusion?