Restarting the `int/uint` Discussion

internals
191

(cross-posted from the RFC; we’re going with Design 1 with names isize/usize)

The core team met this morning to coordinate on the alpha release and to finalize a decision here. The discussion on the RFC thread, on discuss, and elsewhere has been vigorous and dug deep; thanks everyone who participated!

Summarizing the discussion

I won’t try to fully summarize everything that has been said, but single out the most salient points:

  • @Valloric laid out a vivid description of Google’s guidelines: use i32 for numbers “laughably smaller” than 4 billion; otherwise use i64. We will need to tweak these guidelines to also cover our pointer-sized types, but they greatly clarified that having a “default” int type is problematic.

  • The discussion on the RFC thread has covered the pros/cons of various renamings of int/uint. This is a difficult question at the intersection of clarity, learnability, and friendliness to newcomers.

Of course, many many other interesting points were made along the way, and I encourage those interested in the topic to read back through the threads for more.

The decision

In the end we chose isize/usize, partly due to arguments summarized by @1fish2: keeping the i/u prefixes makes it easier to understand that they are part of Rust’s family of integer types and follow the same rules. Similarly, @iopq’s point that “having isize/usize seems like ONE additional type with a prefix” makes a compelling argument against size/offset, which appear to say that the two types have a different relationship than our other prefixed types.

On the other hand, seeing usize in the context of slice indexing or as the return of the len function is unlikely to lead to too much surprise for newcomers. A type like umem, on the other hand, is likely to raise eyebrows. Since “size” is general enough to refer to both the size of the address space and the size of a container and its indexes (which are, of course, closely related), and reasonably intuitive, we feel it is the best choice.

The plan

Here’s what needs to happen next:

  1. @CloudiDust, can you please update the RFC a final time, giving isize/usize as the “Detailed design” and leaving the others as alternatives? Once that’s done, I will merge the RFC.

  2. We will introduce isize/usize before the alpha release, and deprecate int/uint.

  3. I will very soon post an RFC proposing formal conventions around integers, based partly on @Valloric’s comment above. These do not need to be approved before alpha, but should be approved ASAP.

  4. During the alpha cycle, we will revisit all uses of int/uint and change to a specific integer type based on the conventions above. This is one of the few places where we anticipate changes to #[stable] APIs during alpha. (The broader story about the alpha cycle will be detailed in the upcoming alpha announcement.)

  5. By the beta release, we should be ready to remove int/uint.

  6. Separately, we should consider ergonomic improvements to ease the pain of having no “default” integer type. See this thread for early discussion of a number of ideas. These changes are backwards-compatible and can be made more slowly over time.

12 Likes