Rust proposal suggests unative integer for fastest target arithmetic

What unative is trying to solve

A new Rust forum proposal is reopening a familiar low-level question: if you care about arithmetic speed, why should “native” mean pointer-sized at all? The idea behind `unative` is to pick the widest integer the target can handle efficiently in hardware, especially for multiplication and division, instead of defaulting to `usize` or a fixed width like `u32` or `u64`. On the forum, the proposal was framed as a way to give numeric code a better match for the machine it runs on.

That distinction matters because Rust already gives you exact control when you want it. The current primitives are explicit about size, signedness, and pointer semantics, so the debate is not about losing precision. It is about whether the language should expose a separate concept for the arithmetic sweet spot of a target, rather than forcing you to encode that choice indirectly.

Why `usize` is the wrong mental model for some code

Rust’s docs draw a hard line between pointer-sized integers and ordinary arithmetic types. `usize` and `isize` are defined as pointer-sized, and the Reference says `usize` has the same number of bits as the platform pointer type and can represent every memory address in the process. That makes them a natural fit for indexing, offsets, and memory layout, but not automatically the best fit for raw arithmetic throughput.

That is where the proposal gets interesting for performance-minded code. If you are writing tight loops, math-heavy kernels, or algorithms that spend most of their time on multiply and divide, the right width may be the one the CPU handles most efficiently, not the one that can point to every byte of RAM. The proposal’s supporters are essentially asking Rust to separate “good for memory” from “good for arithmetic,” instead of bundling both under `usize`.

x32 shows the mismatch in the real world

The clearest example is `x86_64-unknown-linux-gnux32`. On that target, pointers are 32 bits even though the hardware exposes 64-bit registers and can do 64-bit arithmetic efficiently. The forum thread for `unative` explicitly uses that target as an example where `usize` would be 32 bits, while an arithmetic-focused native integer could plausibly be 64 bits.

This is not a brand-new concern inside the Rust community. An earlier 2024 forum discussion made the same point in different language, describing the x32 ABI as 64-bit x86-64 registers with 32-bit pointers chosen to save memory. That older thread also shows the same tension the new proposal is trying to address: pointer size, ABI choice, and arithmetic width do not always line up neatly, and they have not lined up neatly for years.

Rust already has a precedent for target-aware capability checks

Rust is not starting from zero here. The standard library and unstable tooling already use target-aware configuration for atomic support, including `cfg(target_has_atomic)` and `cfg(target_has_atomic_load_store)`. In other words, Rust already accepts the idea that hardware capabilities can vary by target and that the language can expose that variation in a structured way.

That precedent matters because `unative` would need the same sort of target sensitivity. If a platform makes one width fast and another awkward, a language-level capability flag is more precise than a vague promise that “native” is always the best choice. Rust’s atomic types reinforce the point too: `AtomicUsize` has the same size and bit validity as `usize`, but its alignment is always equal to its size, which shows how carefully Rust already treats layout, capability, and portability as separate concerns.

Where a fastest-native-width integer would help, and where it would hurt

The strongest case for `unative` is code that is numeric first and layout second. If you are writing a hot path that does not cross an FFI boundary, does not serialize a wire format, and does not need to match an on-disk schema, then a target-specific arithmetic width could make intent clearer than scattering `cfg` gates or hand-picked integer sizes through the code. That is especially appealing in libraries that want to scale across desktop, embedded, and unusual hybrid ABIs without pretending those platforms all behave the same.

The downside is portability friction. A type whose meaning changes with the target can make code harder to read, harder to audit, and easier to misuse at ABI boundaries. Rust’s own Reference emphasizes that built-in types are tightly integrated into the language in ways user-defined types cannot fully emulate, which is exactly why a future `unative` would raise design questions that a normal type alias would not solve. The language would need to decide whether that extra abstraction is worth the risk of turning a performance hint into another portability headache.

That is the real shape of the debate. `usize` remains the right tool when you are counting bytes, walking arrays, or talking to memory. A fastest-native-width integer would only earn its place if it helps arithmetic-heavy code stop guessing about the hardware underneath it, without making cross-platform Rust crates carry yet another ABI-shaped burden.