RFC: Rename int/uint to something better

[CloudiDust]

This RFC proposes that we rename the pointer-sized integer types int/uint, so as to avoid misconceptions and misuses.

This is yet another attempt to rename int/uint. See A tale of two’s complement for reasons of the rejection of the previous proposal.

After community disscussions, this RFC has undergone several major revisions and the originally proposed intx/uintx have lost favour.

The winners are: isize/usize!

Rendered View.

[glaebhoerl]

+1!

I think this is a nice compromise. Familiarity is a double-edged sword: we want the names to be familiar enough so that peoples' initial reaction to them isn't "what is this I don't even", but at the same time we want to avoid giving an impression ("this is the type you should use most of the time") that is misleading and harmful, as int and uint do. Essentially, we want names which make it very clear that these are integer types, without actually being called int and uint. Just adding a single letter to the end, making them intx and uintx, accomplishes this surprisingly simply and well. The previously suggested names such as iptr/uptr, isize/usize were still not obvious enough in the opinion of the core team, which is an opinion I respect; I think these, however, very much are. Most of the characters in the names are now allocated towards describing their "integerness", rather than their "pointerness" or "sizeness", which is as it should be.

I might like the names intp and uintp even better (with the 'p' standing for either pointer (sized) or platform (dependent)), but either is fine, I think; they are close enough to be splitting hairs.

[nagisa]

While I agree that leaving int & uint as they currently are is detrimental, the “x” suffix associates with “eXtension” to me and I feel that a better suffix can be found and agreed upon.

[Ericson2314]

+1 when I first saw the names, I didn't know what they meant--that's exactly what we want!

[gwillen]

+1 for renaming-away 'int' and 'uint' to something else. This seems as good an approach as any. :-)

[blaenk]

I agree with renaming in general and was disappointed to read the post about deciding not to, especially given the flimsy rationale.

No matter what our best intentions will be, no matter how many times we spam people about the fact that they should really only use int/uint if they need to, they will misuse it.

And it'll be much harder if not impossible to make this change post 1.0.

[arthurprs]

I'm fine with the current int/uint. Although if this lands please consider intz uintz as the z reminds of size and x dont't carry any meaning.

[tshepang]

intx/uintx is a lot uglier than imem/umem; the latter was rejected for, in the words of @blaenk, flimsy reasons

[thestinger]

@glaebhoerl:

I think this is a nice compromise. Familiarity is a double-edged sword: we want the names to be familiar enough so that peoples' initial reaction to them isn't "what is this I don't even"

Uh, that's exactly what appending an x to the name is going to do. It makes absolutely no sense. On the other hand, using names like imem/umem makes the definition clear from the name. I don't see how an arbitrary suffix is an improvement... and it's in no way a "compromise".

Essentially, we want names which make it very clear that these are integer types, without actually being called int and uint.

The i and u prefix is already enough to make that clear. The names of the fixed-size types are simply the sign prefix and a size prefix. It makes sense to use a consistent naming scheme, and consistency here means using u{size_suffix} where size_suffix would be mem, ptr, addr or similar to refer to the memory-addressing-based definition.

The previously suggested names such as iptr/uptr, isize/usize were still not obvious enough in the opinion of the core team, which is an opinion I respect

This was not given as the reason for rejecting it... and it wouldn't make sense anyway. The existing integer types use {sign_prefix}{sign_suffix} so these are an exception to the rule. I'm not aware of precedents for this naming in other languages, so there's no familiarity argument. A language using the same name to refer to something completely different is an argument against a feature, not in favour of it.

The reason we were given is that it's too late to make a breaking change like this, despite the fact that more significant breaking changes are being made for things they want to change.

[thestinger]

This proposal doesn't make the definition of these types any clearer from the name. The rationale for the rejection of the previous far superior proposal was that it's too late in the game to make a change like this. Nothing has changed about the release cycle, and making the same proposal with the focus on far less sensible names is not going to get anywhere. The last proposal was fairly open about the specific names and the rejection was really of renaming these types at all.

The previous proposals to change the name were ignored by the core developers for a long time and then rejected with the logic being that it is too late to make a breaking change like this. There are still far bigger breaking changes in syntax and even semantics occurring at this point so I find the reasoning very difficult to follow. A renaming like this can be done with a simple guided search and replace, which is far easier to cope with than most other breaking changes.

This was brought forwards as an issue by many in the community as early as October 2013 (rust-lang/rust#9940). It was brought up again in several other issues and at least one other RFC (#161) before I suggested starting over with a very clear rationale and plan. There was overwhelming consensus for the last RFC and it was still rejected.

Anyway, I'm strongly against this RFC and I expect that many of the people who supported the last one are in the same boat. The decision on it was clearly made without considering the discussion that occurred and applying common sense. It's pretty damning that no one who was there pointed out how easy it is to do a search-and-replace compared to the difficult of coping with something overflow becoming ill-defined instead of wrapping. I wouldn't be surprised if this RFC was accepted simply because the core team is not a rational actor.

I think it's far more likely that the core team members simply disliked this but couldn't justify it, and came up with some crappy talking points to tell us after the fact. I don't think they're completely incompetent, but it's clear that they're not above endless lying and manipulation based on their past actions.

[ghost]

+1 for changing the name to anything but int/uint. I like the (already proposed in comments) intp/uintp option, but anything will do.

[huonw]

The rationale for the rejection of the previous far superior proposal was that it's too late in the game to make a change like this.

The post gives at least two other concrete reasons just below the single sentence discussing the break-the-world reason. (For some unfortunate reason which I don't understand, the entire community discourse since the posting of that post has basically completely avoided mentioning those two at all.)

[jfager]

Ok, adressing the two ither reasons given:

• "We can document our way out of the problem": this isn't actually a reason against renaming, its a workaround for an acknowledged problem with not renaming. It is also highly debatable.
• "We didn't like the alternatives": subjective feelings are not concrete reasons. Also not clear why unliked alternatives should be disadvantaged against the unliked status quo except for inertia, which is just the 'too late in the game to change' argument stated differently.

[thestinger]

The post gives at least two other concrete reasons just below the single sentence discussing the break-the-world reason. (For some unfortunate reason which I don't understand, the entire community discourse since the posting of that post has basically completely avoided mentioning those two at all.)

I'm not seeing any rationale there.

We believe that adjusting the guidelines and tutorial can be equally effective in helping people to select the correct type. In addition, using i32 as the choice for integral fallback, in particular, can help to convey the notion that i32 is a good "default" choice for integers.

This isn't a reason against renaming it. It's claiming that documentation changes can be equally effective in helping people to select the correct type. However, it's not denying the fact that documentation changes combined with renaming the types would be more effective than either one, and no one was proposing that we leave the documentation alone. It's nothing more than a logical fallacy. No one was arguing that the renaming should occur instead of changing the documentation...

All of the alternate names also had serious drawbacks. For example, the type iptr strongly suggests that the value is a pointer cast to an integer. Similar concerns apply to isize, index, offset, and other suggestions. Ultimately, pointer-sized integers are used for many purposes (indices, sizes, offsets, pointers), and we don't want to favor one of those uses over the others in the name. We did produce alternate branches using the names imem/umem as well as isize/usize, but found that the result was fairly unappealing and seemed to create an unnecessary barrier to entry for newcomers. Ultimately, whatever benefits those names might offer, they don't seem to outweigh the cost of migration and unfamiliarity.

This part raises the sensible argument against iptr and uptr that was brought up in the discussion and directed it towards alternative naming choices. It tries to paint all of the naming suggestions with that brush but there's broad consensus that while imem and umem are not as clear about the precise definition (but are still much more clear than int and uint) they do not introduce any new form of confusion. There is no argument against those names here - it's just a bunch of unsubstantiated talking points and rhetoric. Words with negative connotations don't make an argument.

[thestinger]

For some unfortunate reason which I don't understand, the entire community discourse since the posting of that post has basically completely avoided mentioning those two at all.

The community clearly isn't interested in the FUD the core developers choose to spread over and over. The fact that both the broad consensus and the in-depth reasoning in the discussions is ignored is further proof that a community-led fork of the project is necessary. The problem is not the "entire community", it's the small group of seemingly incompetent people who think they're so much better.

[thestinger]

Ignoring the community concern about this for over a year and then closing the issue with "too late" as the main argument against it is exactly the kind of manipulative politics that the core developers are so fond of. It's unbelievable that this issue was completely disregarded for that long. Stability attributes and the planned 1.0 release have been abused countless times as a tool to land sweeping changes without consensus and justify all kinds of unjustifiable decisions. Seeing it used here is not a surprise.

[huonw]

this isn't actually a reason against renaming, its a workaround for an acknowledged problem with not renaming. It is also highly debatable.

Of course it is highly debatable... but there has been no debate about it until now.

In any case, this is a squishy opinion-based topic with trade-offs and compromise, it's not some sort of mathematical proof: the best balance of pros and cons may involve a few "work-arounds".

This isn't a reason against renaming it. It's claiming that documentation changes can be equally effective in helping people to select the correct type. However, it's not denying the fact that documentation changes combined with renaming the types would be more effective than either one, and no one was proposing that we leave the documentation alone. It's nothing more than a logical fallacy. No one was arguing that the renaming should occur instead of changing the documentation...

It is not a logical fallacy because everything is a compromise: there's pros and cons to changing the name. There's absolutely no reason for the affect of documentation to be the same for uptr/umem as it is for uint, especially since they start from completely different baselines, so we can't reason as if "improve the documentation" improves "ability select the best type" equally for both.

It seems rather likely to me that the marginal effect of "improve the documentation" on umem is smaller the marginal effect of it on uint, meaning this consideration leans towards uint (maybe it's the straw that... tips the scales in that direction, maybe it isn't).

it's just a bunch of unsubstantiated talking points and rhetoric

Both changes were actually implemented as part of the decision making process, and you can see the rendered documentation via the links in the post. (This is again something I don't understand: those links have apparently been clicked fewer than 20 times each, but 32 people have piled on to the discussion on discourse alone.)

It was found that imem/umem was quite ugly in practice. Of course, opinions differ, everyone can make up their own mind by looking over the links in the post.

[ArtemGr]

-1. int reads much better than intx or imem.
I'd rather see an RFC that sticks int to i32.

[glaebhoerl]

@thestinger The goal is only to make people think twice before they reflexively write n: int. Adding a letter suffix, almost whatever it is, accomplishes that: n: intx... "wait, what's the 'x' mean? let me check the docs...". Sure, people can still use it without thinking (that's true with any name), but they're less likely to, which is our aim.

Reading between the lines, the reason the other suggested names were deemed to pose a "barrier to entry for newcomers" and a "cost of ... unfamiliarity" is almost surely because it's still not obvious enough that they are primitive integer types. (Perhaps @huonw can confirm or deny.) Yes, the consistent i and u prefix helps, but not as much as actually having int and uint as part of the name!

[thestinger]

In any case, this is a squishy opinion-based topic with trade-offs and compromise, it's not some sort of mathematical proof: the best balance of pros and cons may involve a few "work-arounds".

If there were cons, you would be able to mention them.

It is not a logical fallacy because everything is a compromise: there's pros and cons to changing the name. There's absolutely no reason for the affect of documentation to be the same for uptr/umem as it is for uint, especially since they start from completely different baselines, so we can't reason as if "improve the documentation" improves "ability select the best type" equally for both.

It has nothing to do with compromise. Improving the documentation about the choice of integers was already planned and is not relevant to with whether they should be renamed. It is a textbook logical fallacy because it's nothing more than an attempt to misdirect from the issue by arguing against the strawman that we can't improve the situation without renaming the types.

I laughed out loud at your bullshit rhetoric here: "It is not a logical fallacy because everything is a compromise". You chose "compromise" as a good talking point and then found a totally irrelevant place to jam it in.

It seems rather likely to me that the marginal effect of "improve the documentation" on umem is smaller the marginal effect of it on uint, meaning this consideration leans towards uint (maybe it's the straw that... tips the scales in that direction, maybe it isn't).

Oh, so you're just going to keep using this strawman argument. Improving the documentation has always been planned, and was an assumption throughout the discussion on the issue. The proposal to rename it is aimed at improving the ergonomics and learning curve beyond what you can do with documentation changes. Pointing at documentation as the only answer is an admission that this part of the language is poorly designed. Naming needs to be self-explanatory because people move between many languages and aren't going to read all of the guides or remember details like this.

It's not an argument for or against this but rather a separate topic entirely...

Both changes were actually implemented as part of the decision making process, and you can see the rendered documentation via the links in the post. (This is again something I don't understand: those links have apparently been clicked fewer than 20 times each, but 32 people have piled on to the discussion on discourse alone.)

I suggest reading the discussion here if you "don't understand" it. The fact that it was implemented doesn't make your logical fallacies and rhetoric any more valid. If you think there are arguments against renaming it, then you should present them instead of continuing to argue from authority and tear down arguments that no one was using.

As usual, a core team member is being very manipulative and is dismissing the community consensus as simply the confusion of people who haven't read the post. It's dishonest, passive aggressive bullshit and you should expect to be called out on it when you repeatedly try to do this.

[liigo]

A big +1, for intx/uintx, or ix/ux (my original[1] suggestion)
1: https://discuss.rust-lang.org/t/a-tale-of-twos-complement/1062/39?u=liigo

[thestinger]

@glaebhoerl: Yes, I get it. It's syntactic salt to force people to do a double take and keep in mind what the types are for. I don't think it makes any sense to design a language that way. There are plenty of self-explanatory names that fit with the existing {sign_prefix}{sign_suffix} model... these x type names do not fit within the existing scheme because their purpose / definition is completely opaque from the name.

I think nearly everyone would agree that intx is uglier than imem or isize so you're not going to make any progress towards overcoming the vague complaints about it being "ugly" if it doesn't have the misleading int name. The blocker for the last proposal was not that the fact that int wasn't included in the name. There are already u8, u16, u32, u64, i8, i16, i32 and i64... and no one was complaining about that or suggesting that we move to int8 / unt8 like C.

The first name that was proposed was uintptr (like C and Go) in 2013 and uintmem would fit in that scheme, but it isn't how Rust chooses to name most of the existing integer types - just the two with misleading names.

[thestinger]

@glaebhoerl: Opening the same RFC in an inferior form is not going to get anywhere... The change that's necessary is replacing the people in charge of the project with ones who aren't so in love with making the decisions behind closed doors without taking into account logic and community consensus.

The only conversations that matter happen in a venue where community members have no chance to correct the seemingly endless misconceptions and misunderstandings of the core team. They've fought on the wrong side of almost all of the major language design issues. It took ages for obvious things like external iterators, unboxed closures and sane io/concurrency to be reluctantly accepted. There are a lot of other design issues throughout the language and libraries that aren't going to be addressed before they proclaim 1.0.

[huonw]

I had a long response written, but I don't think it's worth it if I'm going to get accused of being a bad person anyway.

As usual, a core team member is being very manipulative and is dismissing the community consensus as simply the confusion of people who haven't read the post. It's dishonest, passive aggressive bullshit and you should expect to be called out on it when you repeatedly try to do this.

I was not being trying to be manipulative or dismiss anything. Maybe I'm fundamentally wrong (I don't think I am, but it's possible), but I'm not trying to lie or generally push the conversation downhill/away. It's extremely saddening that malice is being assumed.

[tbu-]

@huonw While I won't necessarily attribute it to malice, I still think that @thestinger's point holds – I also stopped when I read that sentence that the "documentation should be improved" – this sentence is no reason for not changing it, it's just that it might not be as bad. That the other names also have drawbacks forgets to mention that uint and int also have serious drawbacks that were actually seen in action and are still seen.

(Random example from the compiler: Why is the left shift implemented by amounts of uints? This has nothing to do with pointer-size.)

[thestinger]

I don't think there's malice. I think the core team genuinely thinks that being manipulative is a good way to "manage" the problem of having a community.

[ben0x539]

We should just use the full type name for the suffix, since that's what the other numeric types do.

[tshepang]

agreed with @ben0x539

[CloudiDust]

@aturon, will do.

@ben0x539, I agree about the suffixes.

[Valloric]

@aturon Big thanks to you and the rest of the core team for a reasonable decision here. isize and usize are fine, and so are the suffixes. Thanks for continuing to listen to community feedback on this matter even after making an initial decision; this continues the exemplary pattern of the core team changing past designs after more feedback has been received and not categorically closing ranks behind "a decision has been reached" mentality.

Keep up the awesome work!

[nstoddard]

I'm really happy with this decision! Thanks for reconsidering after your original decision.

I'd prefer for the suffixes to be the same as the type names. That's consistent with the rest of the numeric types, and since the suffixes can be inferred most of the time, the 3 extra characters (isize vs is) shouldn't be a problem on the rare occasion you need to include the suffix.

[CloudiDust]

@aturon, I suggest that we try isize/usize as suffixes first, and if this proves painful, we then go with is/us.

is/us are actual words, and is is a keyword in many languages. So this is a -1 for is/us.

OTOH, we can treat 42is and 42 is as different things if is becomes a keyword, though it feels a bit hack-ish.

P.S. I don't have access to an internet-enabled computer until tonight (local time of course), so sorry about not being able to update the RFC now. (My understanding is that we wish to merge this ASAP.)

[emberian]

@CloudiDust we already do treat 42is and 42 is differently, for exactly this sort of reason.

[emberian]

(In particular, all literal suffixes are reserved, and whitespace is required around literals to separate them from other tokens)

[CloudiDust]

@cmr, 42is is would be a bit funny if it ever becomes a thing. :)

But my main concern is that is/us may be too pleasant, 42is vs 42i32 vs 42isize?

[CloudiDust]

@aturon, done.

[aturon]

Thanks @CloudiDust for your tireless effort! I'm going to merge this RFC.

[aturon]

Merged. Tracking issue.

[mzabaluev]

An after-note for register-sized types. As @thestinger and others pointed out, they are not synonymous with isize/usize. These types may be useful for optimization, but using them in a public interface is probably not a good idea for the reasons thoroughly discussed here and in other places. So it's not important whether they are distinct from any other built-in integer types. ireg/ureg (or whatever color you want this bikeshed painted in) may be defined as machine-dependent aliases, similar to the libc types.

[CloudiDust]

#573 has been filed to discuss the suffixes. That RFC proposes isz/usz as a compromise between isize/usize and is/us. (Both isz/usz and isize/usize are fine in my eyes.) Comments are welcomed.