Interesting, this is similar to the discussion going on for "int" in Rust (or the exact opposite, depending on how you view it). [1, 2]
One the one hand "implicit int" are being phased out in favour of explicit int size. Your variables cannot be `int` anymore, you have to sit down, think and choose: u8? u16? u32? i32? u64? i64? This avoids all the pains of programs behaving differently or crashing when compiled on different architectures.
On the other hand, a new "native integer for sizes that do not matter, minimum 32 bits" is being brewed, for example for pointer offsets or collection sizes. The idea is that you will not be able to have a collection with more of 2^32 elements in a 32-bit architecture nor more than 2^64 in a 64-bit architecture.
After this discussion, my hope is to see the introduction of a fast-ish dynamic bigint (that starts native and grow up to 256 or 512 bits) that can be used in all the cases where you do not care about the exact size type, yet you want to be future-proof (this `private int index` fits this case, IMO).
It would affect the standard library of rust, not rust itself I think. Second, the word-size matching the architecture has only a slight performance impact, i.e. operations on a 64-bit word on a 32-bit architecture take more cycles/instructions than 64-bit words on a 64-bit architecture.
It's only important for things like pointers that they match the size of the addressing space, and not even that is a very hard constraint, just a very convenient one.
16 bit architectures are weird enough that a lot of tools don't support them. And 8 bit architectures are basically only used for things like Arduino nowadays.
However, using a 32 bit number to store values that will never be larger than 16 bits isn't that bad, it's just very slow.
One the one hand "implicit int" are being phased out in favour of explicit int size. Your variables cannot be `int` anymore, you have to sit down, think and choose: u8? u16? u32? i32? u64? i64? This avoids all the pains of programs behaving differently or crashing when compiled on different architectures.
On the other hand, a new "native integer for sizes that do not matter, minimum 32 bits" is being brewed, for example for pointer offsets or collection sizes. The idea is that you will not be able to have a collection with more of 2^32 elements in a 32-bit architecture nor more than 2^64 in a 64-bit architecture.
After this discussion, my hope is to see the introduction of a fast-ish dynamic bigint (that starts native and grow up to 256 or 512 bits) that can be used in all the cases where you do not care about the exact size type, yet you want to be future-proof (this `private int index` fits this case, IMO).
[1] http://discuss.rust-lang.org/t/if-int-has-the-wrong-size/454... [2] https://github.com/rust-lang/rfcs/pull/464