RFC: Renaming int/uint

[1fish2]

This RFC adopts Daniel Micay's suggestion to replace RFC: int/uint portability to 16-bit CPUs with a single-purpose RFC to just rename int/uint.

This RFC assumes a fixed-size integer type will become the type inference fallback and thus the language's "default integer type" and, in turn, heavily used in tutorials and libraries. See RFC: Change integer fallback RFC to suggest i32 instead of int as the fallback.

What changed since Daniel's original RFC on this issue?

• Interest in restoring integer type inference fallback, but to a fixed-size integer.
• Interest in the Rust Guide using mostly a fixed-size integer instead of pointer-sized integers.
• Mickaël Salaün found and listed some int/uint portability bugs.
• Gábor Lehel wrote an RFC for checked arithmetic, making that an independent issue.
• Lots more discussions about integer type names. (See the RFC for links.)

While the new choice of names might be considered bikeshedding or not, moving away from long-held expectations on int/uint set by other programming languages is a usability issue.

[Kimundi]

Another possible naming option would be iptr and uptr.

[tbu-]

cc me

[emberian]

I disagree with the names index and uindex because the uindex type is the one that would be used for indexing, not index! I also think index is far too good of an ident to sacrifice as the keyword for this purpose. I think uptr and iptr are the best choice that have the same name, but index and ptrdiff would be better type names I think, if we're willing to take the index keyword for this. If we had "generic numeric literals", these types wouldn't even need to be in the language, and could instead just be regular types in libcore.

[tbu-]

@cmr I propose we delay the bikeshedding until this RFC is agreed upon (modulo the naming).

[gioele]

@tbu-: I am confused, what is to be agreed up if not the naming? The RFC states the proposal as

Rename the pointer-size integer types from int and uint to index and uindex to avoid misconceptions and misuses. They aren't the default types you're looking for.

[vks]

One issue that is not discussed in the RFC is that uindex will be also the type used for sizes. While I personally don't care, people might find counterintuitive that Vec.len returns a uindex.

[gioele]

Ranges have the same problem: it seems unnatural to have uindex as the type of i in

for i in range(0u, 10) {
    println!("i = {}", i);
}

[vks]

@gioele The RFC assumes that a fallback to i32 will be implemented, so you don't need that annotation. We might consider renaming the suffixes though.

[Thiez]

I have to agree with cmr here, it would be confusing if the index type was not actually used for indexing. I also quite like uptr and iptr, with index and ptrdiff as a second choice.

[l0kod]

I would also add the argument that the renaming process would be the good and probably only time to spot future bugs before they appear.

There is also the question about integer suffixes i and u. They must change (or disappear) accordingly to the int/uint, otherwise the bugs related to this names will surely remains in the existing code.

A good example of using uindex (or uptr) and not index (or iptr) should help too: object indexing and object length (not sure anymore)?

[arcto]

I think too that the intand uint names should be changed. index however, as pointed out by @cmr, is too valuable as a descriptive identifier name. Change the keywords, but to some other names.

[l0kod]

Some discussions about the naming are in the forum and in #161.

Some arguments found there :

• One problem with names like index, size, and offset, besides the plain lack of familiarity, is that it might not be immediately obvious that this is an integer type at all. (from @glaebhoerl)
• That may be a good point to have an unfamiliar type name.
• Maybe if we took off that implicit constraint, then we could arrive somewhere interesting, like uaddr and ioffset. Since, you know, the signed case arises from pointer arithmetic and thus it makes sense to talk about as a relative offset versus the unsigned being an absolute address. Of course, going down that road might lead one to them attempt to encode rules in the types like uaddr + ioffset -> uaddr and make addition of uaddr itself illegal, while uaddr - uaddr -> ioffset. Kind of funny looking. (from @pnkfelix)
• A usize will be more explicit than the uaddr (a size must always be positive) and is more abstract than an address. A ulength or ulen type make sense too.
• isize and usize are short enough, get the point across, are familiar to those coming from C, and match the prefixes used for other integer types. (from @rkjnsn)
• Calling them isize/usize wouldn't really be correct. The maximum object size (including for arrays) needs to be capped 1 bit lower than the pointer size. The types are defined as having the same number of bits as pointers, not as a way of measuring sizes. (from @thestinger)

That said, I like the iptr and uptr because they refer directly to the (variable) pointer length like i32 refer to the 32 bits length.

[vks]

I like the possibility of using different types for an address and a size, even if they are the same primitive type. It solves the problem that uptr/uaddr and usize are both "wrong" if used for both cases.

It might make simple loops that index all elements of a vector annoying if there is no implicit conversion though. (The highest possible address is the size - 1.)

[thestinger]

@vks: It's not correct to use int / uint for sizes in all cases. It only works when the size is bounded by the address space. For example, bit vectors and arrays of zero size types are artificially restricted by the use of uint - which is not necessarily a bad thing, but it's something to be aware of (it has been a pervasive soundness issue).

[thestinger]

I think we can separate the issue of whether they should be renamed to something to do with pointers / sizes from bikeshedding the specific names that are chosen. I strongly support the RFC, although I would prefer uptr / iptr as the specific names. It's nice that both names have a sign prefix like the fixed-size integer types, and the definition is extremely clear. I still think the alternative names like intptr / uintptr and index / uindex would be a significant improvement over the status quo.

[glaebhoerl]

I think you might've meant to link to a different page here, because this one doesn't include {s,}size_t. Perhaps this one? (But even that doesn't mention ssize_t.)

[l0kod]

https://en.wikipedia.org/wiki/C_data_types#Size_and_pointer_difference_types

[vks]

@thestinger I agree that this is an artificial limitation, but I really don't see an alternative at the moment, because there is no u64+3 or bigint in Rust. If that is really a problem in practice, it is possible to implement a BigVec that has a bigint as size.

I also like uptr and iptr the most.

[thestinger]

It's a reason not to name the types isize / usize because they're really defined in terms of the address space size. The maximum object size may be significantly lower, although the theoretical upper bound is determined by removing 1 bit from the address space size.

[1fish2]

Great points, everyone. This revision gets in most of the feedback.

[Gankra]

I'm another vote for iptr and uptr. Short, simple, clear.

I'd also still be interested in having a uint and int type as synonyms for u32 and i32 for a programmer to signal that the size of integers has not seriously been reflected upon. I get the impression this is what mostly people are using uint and int for outside of their "intended" use. This also matches precisely with when int fallback is expected to kick in: the programmer wanted numbers (possibly just as some vague dummy data), but hasn't clearly reflected on the types of these numbers.

Not sure if this is out of scope for this RFC or not. I'm genuinely a little lost on the full hierarchy/relationship of all these different int RFCs.

[vks]

I'm not convinced having int as a synonym for i32 is the right thing to do. i32 is a more precise name, and does not hide the limited range of numbers it can represent. We can teach Rust programmers in the guide to use i32 as a default.

(I don't think that it is an unimportant detail that can be glossed over, because the programmer should be conscious about the limits of i32. If we defaulted to bigints like for instance Python, we could get away with glossing over the details.)

[l0kod]

I'd also still be interested in having a uint and int type as synonyms for u32 and i32

Agree with @vks, moreover we would miss the opportunity to fix the code currently using int/uint.

Same argument for dropping u and i suffixes (for now).

[arcto]

I also agree with @vks on int/uint; the ranges of integer types are too essential to not consider. Please take this opportunity to eliminate a whole bunch of bugs.

I'd also like to give my +1 to either of these alternatives:
iptr, uptr (shorter)
intptr, uintptr (perhaps clearer)

[glaebhoerl]

I concur with prior commenters in that my particular preference among the possible alternative names is completely secondary to my preference for any alternative names. The core team can just settle that debate by choosing whichever names they like best, as long as it's not int and uint, as far as I'm concerned.

That said, my particular preference is still isize and usize. Not because I think it's perfect (such a thing doesn't appear to exist), only because I think it's less imperfect than the others. I acknowledge that it's not completely precise, but I think it's plenty "close enough" and more intuitive.

This page says:

On many platforms (an exception are systems with segmented addressing) std::size_t can safely store the value of any non-member pointer, in which case it is synonymous with std::uintptr_t.

Does or will Rust support any platforms where this does not hold?

I think the other names are likely to be more confusing when someone first encounters them:

• iptr, uptr, intptr, uintptr: "What have pointers got to do with it? Is there something unsafe going on?" These names are very descriptive in terms of how the types are defined, but not in terms of why they matter. Rust doesn't have pointers in safe code, yet these types are still important there. Put another way, they feel like an implementation detail leak. It happens to be the case that for indexing into an array, you want an integer type with the same size as a pointer, but this fact is not prominent in most people's minds. (My recollection is that it took a while for this use case to surface even in the Rust community's early discussions regarding "why do we need pointer-sized integers at all?", with most people initially turning the discussion to unsafe code. Unfortunately I can't find the discussions I'm thinking of, so I'm not sure if my recollection is accurate. But if it is, and even the people working on Rust needed to be reminded of it, then there is surely little hope for anyone else.)
• index, uindex: These have the reverse problem. As previously noted, it may not be immediately obvious that index is an integer type at all.

I think isize and usize strike a good balance between these conflicting imperatives.

(Again though, I think any of these problems are smaller than the ones which int and uint have.)

[Kimundi]

Looking at all the suggestion here again, I think I could accept either of iptr/uptr and imem/umem

[vadimcn]

iptr/uptr please

[1fish2]

Is there anyone who prefers the names int and uint for these two machine-dependent integer types with the same width as a target platform pointer?

[netvl]

@1fish2, yes, I personally think that int/uint are fine, but as far as I can see everyone else think otherwise :)
But, frankly, renaming them does make sense.

[codyps]

@1fish2 +1

[pnkfelix]

(jf we are going to rename, I would prefer imem/umem over iptr/uptr.)

[nodakai]

I totally agree with @glaebhoerl in both of these two points:

1. Banishing int / uint is much more important than choosing specific names (as emphasized by @thestinger , too)
2. Prefer isize / usize to iptr / uptr because: "What have pointers got to do with it? Is there something unsafe going on?"

[gulbanana]

It'd be great to do away with the legacy of 'default ints' as variably sized. Most of the suggested names seem better than the status quo. (I like iptr and uptr personally; the primary argument against this is that it doesn't make sense unless you've learned things, but you have to learn those things to reasonably use rust..)

[barosl]

It seems that the bikeshedding is stalled, but I hope this would land before 1.0. I try to use i32 wherever possible, but I often carelessly choose int because it is allowed by the language.

Personally I am OK with either umem or uptr. I have a slight preference on umem because it may confuse newcomers less (0um and 0im is prettier than 0up and 0ip, too!), but I also like uptr because it reminds me of uintptr_t in C.

[1fish2]

I wrote in the intro:

This RFC assumes a fixed-size integer type will become the type inference fallback and thus the language's "default integer type" and, in turn, heavily used in tutorials and libraries.

but a BigInt type would fill the type inference fallback role at least as well. I should've written "a platform-independent integer type"...

[l0kod]

As Rust will soon reach 1.0 and because of the (invasive) breaking change, this RFC should quickly be accepted, otherwise it will never land.

cc @pnkfelix

[nrc]

@l0kod the Rust team discussed this at the work week (week before last), there is broad support for a renaming, but discussion about the details is ongoing and theirs still some work to do to find consensus. It's definitely on our minds though!

[rkjnsn]

I want to add that I strongly prefer imem/umem over iptr/uptr

[1fish2]

I posted a poll on G+, phrasing it as a time-travelling C change to include programmers unfamiliar with Rust.

Anyway, I agree that the main point is to change the name, and I personally prefer imem & umem.

[vks]

I posted a poll on G+, phrasing it as a time-travelling C change to include programmers unfamiliar with Rust.

Does it tell you how many people voted on it?

[tbu-]

@vks The vote count is right above the picture for me. Currently 6 people have voted.

[liigo]

iptr/uptr looks fine for me. imem/umem doesn't make sense because
everything else are memory too.

[tbu-]

@liigo The reasoning for imem/umem is that it represents a memory address, it's sized so that it can address the whole memory.

[nrc]

This was discussed a lot by the Rust team and the core team and, eventually, decided against. See this post for more of the reasoning behind the decision

[l0kod]

Despite all the favorable comments about this great RFC, the fear of a new breaking change (even before the 1.0 milestone) was greater... 😞

[thestinger]

@l0kod: It's clearly not why because changes like opt-in Copy or most of the other recent breaks were harder to deal with than a guided search / replace. The second stated rationale is the issue of familiarity which is clearing missing the entire point. Familiarity is a bad thing because these types are defined differently in other languages. No one is going to infer that i32 is the type for general purpose usage and int is a pointer-size integer from the names.

The decision was made based on closed-door discussions without people who understood the motives behind the RFC. The public explanation likely has very little to do with the conversions that actually occurred. I don't know why anyone would still expect the core developers to be open and honest.

[wycats]

The decision was made based on closed-door discussions without people who understood the motives behind the RFC. The public explanation likely has very little to do with the conversions that actually occurred. I don't know why anyone would still expect the core developers to be open and honest

I'm genuinely unsure what you mean by this. Maybe there's an ultra-secret core group that is making decisions without me and has even more ultra-secret motivations, but at least for me, the stated rationale is the rationale we discussed as a group.

[thestinger]

@wycats: I don't place much weight in the word of someone who makes personal attacks on me in private discussions after putting on a completely different persona in conversions with me. I know for a fact that there's even internal dissent about the way this went down because I was told by at least one person who was there.

[wycats]

@thestinger I'm pretty sure I would tell you (to your face) anything I've said in private to anyone. I think that you are very talented and have many very good insights on issues. I believe that Mozilla has a need to grow the core team so it includes people who are not employees of Mozilla, and I have strongly advocated for that for nearly a year now. I also believe that if you're worried about Mozilla influence, your best bet is on the continued growth of the Rust community, who will naturally dilute the influence that Mozilla has now as one of only a few companies paying multiple people to write Rust code every day.

On the flip side, I feel that you have been both technically sloppy and vitriolic in your comments (this is not a personal attack, just an observation). I feel that the way that you talk about Rust and the core team is actually more likely to leave a trail of damage in your wake than achieve your goals of more diversified decisionmaking. In private, I have absolutely vented about the frustrating way you have chosen to engage with the community.

The frustrating thing for me is that I have largely agreed historically with many of your technical critiques and your organizational critiques, but I've watched the core team (both before and after I joined) take your concerns extremely seriously. They haven't always agreed with you at the end of the day, but they have spent countless hours seriously engaging with every technical critique you've raised, and have often come to agree with you.

In response, you have ratcheted up the level of vitriol and conspiracy theorizing, and have repeatedly and publicly threatened to fork Rust. I'll ask you again what I asked you in private: if you're interested in the success of Rust, please try to work as a collaborator, rather than as an enemy. I would welcome collaboration with both arms.

[thestinger]

I'm pretty sure I would tell you (to your face) anything I've said in private to anyone.

That's clearly not true, as you pointed out yourself later in this comment.

I believe that Mozilla has a need to grow the core team so it includes people who are not employees of Mozilla, and I have strongly advocated for that for nearly a year now.

Including contractors instead of just normal employees isn't much of a change.

I also believe that if you're worried about Mozilla influence, your best bet is on the continued growth of the Rust community, who will naturally dilute the influence that Mozilla has now as one of only a few companies paying multiple people to write Rust code every day.

The problem isn't the influence of Mozilla. It's the fact that there's so much influence by people with no respect for the community or the project. It's a problem with people who are unable to approach technical issues without their personal bias / feuds getting in the way and who resort to dishonest, manipulative tactics to push their point of view. Mozilla's involvement just guarantees that these will continue to be the people in charge.

On the flip side, I feel that you have been both technically sloppy and vitriolic in your comments (this is not a personal attack, just an observation).

This is just laughable bullshit. The only time I'm vitriolic is in response to two-faced liars like yourself. I think FUD deserves to be called out, as does nasty political nonsense like like certain people who felt it necessary to block my pull requests with whatever pile of bullshit reasons they could pull out of their ass.

You calling my contributions technically sloppy is just a projection of your own incompetence. You don't have any real arguments to make so you're just going to totally misrepresent the facts. That's the usual pattern that I've grown to expect.

I feel that the way that you talk about Rust and the core team is actually more likely to leave a trail of damage in your wake than achieve your goals of more diversified decisionmaking.

I suggest cutting down on the FUD and manipulative tactics if you don't want to be called out on it.

In private, I have absolutely vented about the frustrating way you have chosen to engage with the community.

I've only "chosen to engage" like this with a select few people on the core team. People who habitually resort to lying / manipulation / politics have no place managing a community like this.

The frustrating thing for me is that I have largely agreed historically with many of your technical critiques and your organizational critiques, but I've watched the core team (both before and after I joined) take your concerns extremely seriously.

They haven't always agreed with you at the end of the day, but they have spent countless hours seriously engaging with every technical critique you've raised, and have often come to agree with you.

This isn't about technical issues. The problem is a lack of openness, manipulation, lying, taking credit for other people's ideas / work, putting procedure above common sense and letting personal politics drive decision making / actions rather than the good of the project.

In response, you have ratcheted up the level of vitriol and conspiracy theorizing, and have repeatedly and publicly threatened to fork Rust.

Once again, you're using manipulative language like "conspiracy theorizing" to white-wash real cases where the community has be abused. You're the one ratcheting up the vitriol by misrepresenting everything and resorting to so much passive aggression.

I'll ask you again what I asked you in private: if you're interested in the success of Rust, please try to work as a collaborator, rather than as an enemy. At least I would welcome collaboration with both arms.

I have no interest in collaborating with pathological liars. You said a lot of things to me in private that I've had to re-evaluate after finding out it was just a show.

[stefanpenner]

Happy holidays everyone!

[franontanaya]

i0 as opposed to i32 and i64 would look to me like a not fixed size.

[thestinger]

@franontanaya: A pointer-size integer is not the only useful architecture-specific integer type.