Call for consensus, if we do want rename `int/uint`


Now, there are too many candidates to replace int/uint:

  • iptr/uptr
  • imem/umem
  • idiff/usize
  • intptr/uintptr
  • intx/uintx
  • ix/ux
  • intptr/uintptr (for pointer type) and intreg/uintreg (for word type)
  • … and all others

Almost any one is better than int/uint, but we must focus on one of them. Or, if fragmented, we maybe lose the last opportunity to rename int/uint before Rust 1.0, that will be unfortunate. So I call for consensus.

I personally prefer ix/ux, since it have two unique advantages, while other candidates haven’t:

  • ix/ux is named the same way as other integer types, e.g. i8/u8/i16/u16... (x means a non-fixed/machine-dependent number)
  • ix/ux literal’s suffix is the same to its type, e.g. 0ix/100ux

From what is known, Rust always try avoiding exception. int/uint is already an exception, will we introduce another exception replacer? I don’t think so.


I prefer isize/usize. in C/C++ people know size_t to be the size of a pointer, so people coming from there will understand it, and any of those choices will be understood after some RTFM :wink:


isize/usize is too specific (length), when used as index, it’s weird.


I am late to the party, but I am against renaming int/uint. I think changing default int fallback to i32 (which is accepted) is good enough and none of proposed names are good.


Have you seen that they’re widely misused? In the other thread, I just pointed out an oversight in the standard library itself.


The standard library is still far from perfect. If there are misuses of int/uint there I believe we should fix them.

FWIW, I also believe int/uint are fine.


So for what it’s worth, my preferences are:

First of all, for any names other than int/uint;

Second of all, within that, for names which put the emphasis on the “integer” half of things, rather than on the “pointer” (or whatever) half;

And within that, for intp/uintp in particular. I like it for essentially the same reasons that others gave for liking iptr/uptr: it’s simple and precise. It does still carry some of the same hazard as those did (and which I raised as an objection to them), that people may interpret it as “pointer to int”, or something of that nature. This is a subjective judgment call, but I personally feel that with these names it is now low enough, and that the ‘p’ is more clearly just a modifier on the ‘int’. This also cleanly allows for adding e.g. intr/uintr for register-sized integers, or whatever, in the future.

A close second are intx/uintx; and out of the remainder, I like isize/usize. The only ones I actively dislike are ix/ux, which I feel are too cryptic. (Still better than int/uint, but now only a lesser evil.)

As far as the “consistency” argument goes, I think that one way to think about it is that all of the names “start out” as int16, uint32, etc.; and then we notice that these can be abbreviated to just i16, u32, etc., without significant loss of clarity, because of the implicit separator between the “letters part” and the “numbers part”, which makes it clear that it should be read as a “u” and a “32”, which can then reasonably be intuited to mean “unsigned” and “32 bits”. On the other hand, for intp/uintp or intx/uintx, this doesn’t work, because in ix/ux or ip/up, it’s not clear that the letters are supposed to be taken separately, as “i” and “x”, rather than as a single, indivisible word. Intuiting that “ux” means “unsigned” and “variable bits” takes quite a leap of imagination.


I’m also in the “anything but int/uint” camp.

I believe it’s a fundamental mistake to allow anti-patterns to occupy the simplest and most familiar integer naming slot.

Both intx/uintx and intp/uintp would be fantastic options. I slightly lean towards intx because the x is very familiar as a wildcard, so once people look it up once, they will readily associate the term as variable across platforms, and therefore only to be used with proper thought.

If int/uint were to retain or regai any meaning, the only decent choice would be as an alias for BigInt/BigUint.


I have updated RFC PR 544 to promote intp/uintp, intm/uintm and imem/umem.

The problem with intx/uintx is that there are other platform-dependent integer types, like register-sized ones, so the names are a bit too generic.

I personally favor imem/umem among the three current candidates. We can say they are “signed/unsigned _mem_ory-pointer sized integers”, instead of the vague “for memory related things”. Granted this is not an obvious connotation, but I believe it can be a lot easier to see once the documentation gets consulted.

intp/uintp come second, as they still may remind people of intptr_t/uintptr_t or “pointer to integers”, and tempt people to make incorrect assumptions, but they are better than iptr/uptr in this regard.

Mixing imem/umem and intp/uintp we get intm/uintm which don’t have the may-be-incorrect connotations of intp/uintp, but also don’t seem any better than imem/umem to a newcomer, so they have the third place in my mind.


I opened up a new discussion on this topic at with a lot more detailed analysis.


I don’t know why they have to be so short. What is wrong with uintptr and intptr? They’re still not too long, and if anything being a little bit longer than the other types should discourage their use in inappropriate situations.


@milesrout There are many legitimate uses of int/uint and they’re widely used – Rust doesn’t want to be a burden in this regard.


@tbu Of course there are legitimate uses of int/uint. That doesn’t mean that it should be highly abbreviated to the point that it is not clear what it is for. A type called int should be the default integer type. That is what that name implies. That is how it is used in every programming language. That is what beginners will assume, and it should be reasonable for them to do so.


I’m not saying it should stay at int, but I’m saying it can be short.

PS: In C, int is not the default integer type, if you want to write portable code.


@tbu Absolutely untrue. In C, int absolutely is the default integer type. Its overflow characteristics are undefined, and relying on it having a bitlength higher than 16 is non-portable, but that doesn’t make it any less of a default.


Just for consistency. Try to ask “why i8/u8/i16/u16... are so short” first.


I’m familiar with size_t from C(++), so usize is nice and obvious (and easier to type without the underscore). Not sure between idiff, ssize or other possibilities.

In a way, the naming doesn’t matter so much as long as things like vector sizes don’t use this type: usize and ssize or whatever they are named should only be used when needing pointer-sized integers (i.e. mostly for compatibility with foreign-language code and a few library internals).


According to as well as , the purpose of size_t is precisely for array and vector sizes, and is not guaranteed to be sufficient to hold a pointer sized integer (although it often is). uintptr_t serves that purpose. If we intended for a type to be for holding a pointer as an integer, I would suggest usize could be confusing.


@dhardy @d3zd3z

Ultimately, Rust’s int/uint don’t share the exact semantics with any of C’s types. E.g. size_t doesn’t guarantee “suitable for storing pointer-sized values”, while uintptr_t doesn’t guarantee “suitable for storing container indices/sizes”, but Rust’s uint guarantees both and is used in both cases. (Note it isn’t practical to abandon uint as the default container indexing/size type, as discussed in the comments of RFC PR 544.)

So I believe that it makes sense to rename int/uint to imem/umem which remind people of none of the C types while still retaining their sizes in the names (“memory-pointer-sized”). But I agree that the complete loss of familiarity is a double-edged sword.

EDIT: the discussions about “the unpracticality of abandoning uint as the default size/index type” happened in the comments of RFC PR 544, not in the RFC itself. Sorry for the confusion.