Proposal

Summary and problem statement

Currently, rust has a single pair of platform-dependant integer types, usize for unsigned, and isize for signed. This type is used in code as both the pointer sized type (hereafter uintptr_t) and the index size (hereafter size_t). [[RFC 544]])(https://rust-lang.github.io/rfcs/0544-rename-int-uint.html) describes these types as only the former, but code, particularily including unsafe FFI, treats it as the latter. While on most platforms, this is not an issue, other platforms, such as w65/65c816 (with the ABI defined by https://snes-dev.github.io/abi/v1), and CHERI, have differing pointer sizes from index sizes, thus size_tand uintptr_t have different sizes (and are also incompatible in ABI).

Motivation, use-cases, and solution sketches

As mentioned above, the fact that rust informally treats these types as the same impacts the targets that can be supported. Thus, this is motivated in that it enables such targets, such as the aformentioned w65 abi, and CHERI.

There are two major solutions for this (with known drawbacks):

1. Acknowleding that usize is uintptr_t and not size_t. This is not necessarily a de jure breaking change, but may be a de facto breaking change as a significant set of FFI code uses usize erroneously for size_t in signatures. This would work best in conjunction with a proposal such as Add c_size_t and c_ssize_t to std::os::raw. rust#88340 or an equivalent language proposal for a c_size_t type.
2. Change usize to be size_t only, and deprecate it's use as uintptr_t. This is a breaking change, but it may be permissible if applied in old editions only to new platforms. This would be combined with a lint for pointer-to-usize casts on existing targets, which could then be a hard error on platforms where uintptr_t!=size_t, and a hard error on all platforms in a future edition.

The initiative should explore both solutions and collect evidence of the impact of making one choice over the other, before proposing the final solution, which may just be doing nothing, or acknowleding that rust does not support such platforms.

Links and related work

Zulip Thread: https://rust-lang.zulipchat.com/#narrow/stream/136281-t-lang.2Fwg-unsafe-code-guidelines/topic/.60usize.60.20vs.20.60size_t.60 (archive).

IRLO Thread: https://internals.rust-lang.org/t/pre-rfc-usize-is-not-size-t/15369

ABI Discussion for w65 (a target that this affects): https://internals.rust-lang.org/t/abi-discussion-for-w65/15092

RFC 544 (linked above) acknowledges at least a potential distinction between usize and size_t (resp. isize and ssize_t) in stating a drawback for choosing the names usize and isize.

Initial people involved

• Owner, if known: I would be willing to serve this role.
• Liaison

What happens now?

This issue is part of the lang-team initiative process. Once this issue is filed, a Zulip topic will be opened for discussion, and the lang-team will review open proposals in its weekly triage meetings. You should receive feedback within a week or two.

This issue is not meant to be used for technical discussion. There is a Zulip stream for that. Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.