Change integer fallback RFC to suggest `i32` instead of `int` as the fallback

[tbu-]

Rich diff

[1fish2]

For this use, I suggest that int is worse than i32 on 16-bit architectures. The range of i16 is too small in practice to select without careful analysis.

[1fish2]

Yes! In selecting the fallback type, we should rule out platform-dependent types due to portability bugs.

We can rule out unsigned types because the values sometimes need to be signed. Rule out i8 and i16 since they're too small to use without careful analysis.

That leaves i32 and i64. There's a weaker case here. i32 is faster. Many programmers will expect the default to be i32 from their past experience from other languages and most C/C++ calling conventions, where i32 has worked well.

[P1start]

Changing the fallback to i32 seems a bit pointless if int still represents a pointer-sized integer: the name int will be the type people will use for integers simply because of the name. IMO the fallback should always be int, but int should be redefined to be a 32-bit integer (but not a synonym of i32), and int and uint should be renamed to something like index and uindex (or whatever).

[thestinger]

@P1start: I don't understand why we would want redundant integer type... especially if it wasn't just an alias and forced the usage of casts. The i32 type is very clearly named and would be a better type inference default than a pointer-size integer only useful for computing pointer offsets within objects. I don't think it's a good idea to have a hardware integer type without a name communicating the size.

[P1start]

What I mean is that there’s an advantage of having an integer type that is just ‘an’ integer type, and not any size in particular. (It could still be 32 bits, but that would not be much more than an implementation detail. There could be an attribute, for example, to change its size.) A lot of the time when people write int, they just want any integer type that is reasonable for arithmetic and so on. Forcing them to consider the size has upsides, but it also can get in the way when it doesn’t really matter.

It’s just an idea, really: having a redundant integer type is certainly a bit weird. I certainly don’t think int and uint’s names should stay, though, if we change the fallback to something else.

[arcto]

I think this discussion is deviating from the issue: should integer fallback go to the specific size i32 or to the system's pointer size?

I'm for having a specific size (i32) for the reasons presented in the RFC, most importantly portability, predictability.

[thestinger]

What I mean is that there’s an advantage of having an integer type that is just ‘an’ integer type, and not any size in particular.

A hardware integer type with no particular size is not useful. The only suitable integer type in that case would be a big integer.

A lot of the time when people write int, they just want any integer type that is reasonable for arithmetic and so on.

Hardware integer types are not "reasonable" for arithmetic. They are bounded, and using them correctly requires considering the overflow cases.

Forcing them to consider the size has upsides, but it also can get in the way when it doesn’t really matter.

There aren't cases where the size doesn't matter beyond an integer being abused as a boolean.

[dobkeratops]

I think there's a lot of merit to making int "at least 32bits", many programmers expect it; even on 16bit machines, 32bit values were common... 16bit machines weren't limited to 64k ram,etc. There were/are also 16bit architectures that were basically logically 32bits, its just 16bit arithmetic happens to be faster. But you'd need another type which is 'definitely the pointer size'

But imagine if you could select types at compile time:

type MyInt = max<int,i32>; //std::whatever::min<A,B> is some builtin that selects the smallest
type MyIndex = min<int,i32>;

int is whats used for indexing - but does associated types make it easier to get the desired index from the collection now?
(personally I want a Vec with parameterised index, since on 64bit machines I still usually want 32bit indices.. 32bits x 16byte structures is enough to fill memory on many target devices. Vec<T,Index=int>

[Gankro]

@thestinger I think the argument is about offering better type semantics for integer-sizedness. Define int/uint as a synonym for i32/u32 (move old int/uint to some other name), and promote them for programming "in the small" (where overflowing an i32 is rarely a concern-- especially if you're just using them as opaque values for some generic code), and as a way to advertise that the size of the number has not been seriously reflected on. Sort of like stubbing out types.

[tbu-]

@P1start

Changing the fallback to i32 seems a bit pointless if int still represents a pointer-sized integer.

It is not, for the reasons laid out in the RFC text: it is more correct for the cases where the fallback applies.

You are free to open an RFC for the other cases (I would appreciate it), but please don't go offtopic here.

[Kimundi]

+1, falling back to a concrete, clearly defined integer size seems to be less problematic than falling back to the systems pointer size.

[comex]

I'm not sure it's as off topic as you suggest. Shipping one without the other would, in my opinion, leave the language buggy: two cases that programmers would expect to produce a "generic integer type" (a number without context, and a type called int) now give you integers of different sizes. And if int is to become 32-bit then this textual change is not necessary anyway.

[tbu-]

@comex No matter whether int changes or not, this RFC discusses why the current pointer-sized int is unsuitable for integer fallback. If you want other int stuff changed (I also do), please do so in another RFC.

[Ericson2314]

+1. In my view, you shouldn't rely on integer fallback unless you are programming in the small, and I cannot foresee nobody programming in the small on a 16-bit architecture.

Getting rid of int anduint`, and using a index-ish/pointer-ish name instead, will make those NOT being the fallback more understandable, but that is a separate discussion.

[nrc]

The PR seems to change the mode of text/0401-coercions.md, it probably shouldn't.

[tbu-]

@nick29581 Fixed.

[rkjnsn]

👍 if we have to have a fallback, I think i32 makes the most sense.

[tbu-]

@nick29581 Since there's still no negative feedback, can I expect something to happen here? In my opinion we have a clear argument for this RFC (without negative responses!), yet it's still not merged.

[nrc]

@tbu we (the Rust team) spent some time discussing this at the work week, we've got to do some more haggling over the details (aka, consensus building :-) ), expect news soon.

[Valloric]

This would be a great change. 32bit ints are faster than 64bit ints for all the reasons listed in the RFC changes, but just having the default int pinned down to a specific size and not having it architecture-dependent is a massive bonus to Rust's claim of aiming for robust code. Compiling code on two different architectures should not lead to hard-to-track-down bugs.

[nrc]

See this post for more thoughts from the Rust team.

I think this means I can merge this RFC, but I should double check first...

[steveklabnik]

At least conceptually, it should be merged, yes. I haven't read the exact text in a while.

[nrc]

Merging, r=nikomatsakis

[nrc]

Since this modifies an existing RFC, there is no new tracking issue, instead we will continue to use issue 16968