Policy for assumptions about the size of `usize`

[durka]

When in the course of human rusty events, something in core or std depends on the actual width of usize/isize, there are currently (at least) two policies in place:

1. Conservatively assume that usize may be as narrow as 8 bits.
   • example: usize: From<u8> + !From<u16>
2. Liberally assume that usize is at least 32 bits wide (as it is on all current officially supported platforms).
   • example: Range<u32>: ExactSizeIterator

Let me know if I missed any other corners of the standard library which make assumptions (identical to one of these or not).

As these policies are in conflict, it seems like one or both of them should be changed. In principle, we can't remove trait implementations from Range<u32> and the like, so we could just declare target_pointer_width-liberalism to be the law of the land. However, this will make it difficult to port Rust to a 16-bit system. In doing such porting, trait implementations like From<u32> for usize and ExactSizeIterator for Range<u32> would need to be gated by a #[cfg]. But, this would make it difficult to port Rust code from, say, a 32-bit target to a 16-bit target, because some code would stop compiling (N.B. this is already potentially the case, because literals given for enum variants are interpreted as isize literals).

So, what should we do?

[briansmith]

Let's see if we can narrow the bounds just a little.

• I propose that we at least assume that usize/isize are no larger than u64/i64. This implies that we should impl From<usize> for u64 and impl From<isize> for i64.
• I propose that we at least assume that usize/isize are no smaller than u16/i16. Note that this is true, in particular, for 8-bit AVR (Arduino). This implies that we should impl From<u16> for usize and impl From<i16> for isize.
• I propose that there should be a goal, which we don't know how to achieve yet, that libcore and libstd MUST NOT use as for integer conversions, but instead must use only From, Into, TryFrom, and TryInto, etc. for such conversions. The achievement of this goal can then guide the rest of the decision making process.

[durka]

Makes good sense to me. Those proposals still leave the question of what to do about impl ExactSizeIterator for Range<i32>. Options are:

• check crater and attempt to phase it out
• make it conditional on #[cfg(target_pointer_width >= 32)] (pretend that syntax works)
• leave it in and allow (0..u32::max_value()).len() to panic on 16-bit systems

[petrochenkov]

So, what should we do?

Gate impls on target_pointer_width for all currently supported values of target_pointer_width.
When a target with new value of target_pointer_width is added (16 bit, 128 bit, 8 bit, whatever), then new set of cfgs is added as well.

But, this would make it difficult to port Rust code from, say, a 32-bit target to a 16-bit target, because some code would stop compiling

It would make porting simpler because incorrect range assumptions and overflows will be caught at compile time.

[durka]

Caught at compile time when you're porting. If we put in #[cfg(target_pointer_width = "64")] impl ExactSizeIterator for Range<u64> {} then people will be confused when they release a crate, someone downloads it on a 32-bit machine, and Iterator::rposition randomly stops working.

[petrochenkov]

@durka
This is a real problem, 32/64 bits are equally common and often ported between, unlike 16-bit used by very specialized hardware now.
@aturon (IIRC) suggested to add a special lint to avoid these 32-bit <-> 64-bit portability problems.

Impls like From<u64> for usize still need to conditionally exist because a lot of software is supposed to run, for example, on very specific 64-bit server hardware under some enterprise Linux and not going to be ported anywhere.

[durka]

I like the idea of having a lint if an impl is selected that's tagged with #[cfg(target_pointer_width)] (or other target attributes maybe).

[oyvindln]

I propose that we at least assume that usize/isize are no smaller than u16/i16. Note that this is true, in particular, for 8-bit AVR (Arduino). This implies that we should impl From for usize and impl From for isize.

I don't know about wider types, but From<u16> for usize sounds reasonable. C99 and newer recommends the closest equivalent (size_t) to be at least 16-bits.C99 Standard (see page 259). I would think a system where usize would be less than 16 bits (as @briansmith noted, a processor being 8-bit doesn't imply usize being that small) would require rather specialised code anyhow.

[comex]

Maybe a set of special purpose lints?

#[allow(assume_usize_ge_32_bits)]
#[allow(assume_usize_le_64_bits)]

The standard library really should provide some way to safely cast under such assumptions, whether From or something else. If it doesn't, most people won't avoid making them; they'll just hide them in as casts, which are evil.

[withoutboats]

I propose that we at least assume that usize/isize are no larger than u64/i64. This implies that we should impl From for u64 and impl From for i64.

Are we actually confident this is a reasonable assumption over the next 50 years? I guess if it becomes untrue we can make a breaking change.

[aturon]

Nominated for lang team discussion.

[nikomatsakis]

I wrote up the @rust-lang/lang team discussion in this internals thread.