Encourage fixed-size integer

[l0kod]

The #6023 force to use a type suffix for integers. As discussed in rust-lang/rfcs#115 and #9940, the int and uint should only be used for memory-related values (e.g. length).

The documentations mostly use i suffix examples. It should encourage the use of fixed-size integer (e.g. u32) for common uses.

A more strict rule could be to remove the u and i from allowed suffixes, but to rely on full explicit typing (e.g. : int) when really needed.
This could be annoying for range-like functions but it's not that burdensome to use the explicit generic typing (e.g. range::<uint>(0, 5)).

[huonw]

cc #11831

[steveklabnik]

The documentations

Can you be more specific? I also feel like #15526 is related, this may just be a superset of that issue.

[l0kod]

The documentations (i.e. tutorial, guide…) part is definitely #15526.

The strict rule about removing i and/or u can be discussed here.

[thestinger]

I don't think the suffixes should be removed. Fixed-size integers are a better choice for anything not being used for sizes / indexing, but I have a feeling that the most common case is tied to container lengths. I didn't like the fallback because it was prone to causing mistakes, but I don't think we should go out of the way to make things more painful.

[vks]

Currently the documentation teaches new users to use int and uint in a lot of places where it is not related to any container size. Especially int is very rarely related to container sizes (which are never negative).

[l0kod]

cc rust-lang/rfcs#161

[l0kod]

cc #16736

[l0kod]

cc rust-lang/rust-guidelines#24

[l0kod]

cc #14758

[l0kod]

@thestinger, could you please change the label for "metabug" (if appropriate)?

[l0kod]

cc rust-lang/rfcs#212

[l0kod]

Some int/uint bugs:

• Bitv uses architecture-sized uints for backing storage #16736 and libcollection : Switches from uint to u32 in BitV and BitVSet #18018
• capnproto-rust
• capnp-rpc-rust

[l0kod]

cc rust-lang/rfcs#464

[l0kod]

Other int/uint bug:

• Shifts shouldn't be tied to pointer-size integers #20288

[l0kod]

cc rust-lang/rfcs#544

[l0kod]

Another related bug:

• get_ticks returns u32 instead of uint Rust-SDL2/rust-sdl2#200

[l0kod]

Related discussions:

• Integer types
• If int has the wrong size …?
• A tale of two’s complement
• Restarting the int/uint Discussion
• Call for consensus, if we do want rename int/uintinternals bikeshed

[l0kod]

Integer overflow bug:

• LLVM bindings have become incorrect in places. #17795

[huonw]

@l0kod #17795 doesn't seem to be caused by the names/sizes/conventions of integers in Rust. At some point in the past libc::c_uint was precisely correct (LLVM used unsigned int) but then LLVM was changed to use unsigned long long without us realising, causing the FFI declaration to become incorrect.

[steveklabnik]

We've gone through and made a lot of changes related to this, and so I'm gonna give it a close. If we find anything else, it should also be fixed.