6 ms·

It would also be nice to be able to use unsigned types (like u8, u16 and u32) to index into slices and arrays up until usize (usually a u32 or u64). Using a usi

It would also be nice to be able to use unsigned types (like u8, u16 and u32) to index into slices and arrays up until usize (usually a u32 or u64). Using a usize often seems wasteful for indexing into small arrays and slices and casting makes the code look ugly (also dangerous because the effect of casting is checked by the developer, not the compiler). Admittedly, this would have the downside of having code that compiles on one architecture but not another so it’s probably not worth it.

Ygg2 5y ago
Rust supports u16 pointer. Suddenly you are casting u32 to u16. And fun begins.
- davidhyde 5y ago
  Exactly this!
benschulz 5y ago
IIRC integer literals are the blocking issue here. Bounds checking (and elision) happens anyway, but when `Index<T>` is implemented for multiple integer types, `foo[0]` becomes ambiguous.
pwdisswordfish9 5y ago
What’s wrong with .try_into::<usize>().unwrap()?
- ekhjarta 5y ago
  It fails at runtime and not at compile time and it only fails if the value is out of range, so you have to test with large enough values to trigger the assertion during testing. We want to be able to index with integer types that are smaller than or has the same size as usize, but not with integer types that are larger than usize. And we want those checks at compile time.
  - dgb23 5y ago
    Unwrap isn’t an evil thing to avoid completely. The type system cannot understand all invariants, but you can, and you can make sure they are correctly implemented.
    - deleted 5y ago
      [deleted]
- masklinn 5y ago
  .into() will work for u8 and u16, as rust assumes >= 16b pointers.
  - est31 5y ago
    Which totally makes sense. u8 means 256 bytes of addressable memory. You might design chips with such limited memory, but maybe high level (read non assembly) languages are not the right tool for targetting them.
- edflsafoiewq 5y ago
  It's hideous.
dgb23 5y ago
Code looks ugly should maybe not be a big concern in a language like Rust. It’s fundamentally ugly to begin with in many ways. And I think that’s fine because it is a language that is primarily about control. One could argue that this is beautiful in its own way. There’s a clarity and power in being explicit while the constraints let you move on with confidence.
- scns 5y ago
  Function over form. I think it makes a lot of sense in Rusts' domain.
ekidd 5y ago
Rust really doesn't do implicit numeric conversion, and I suspect it would be hard to retrofit. But you could write a function i(...) that promoted u8, etc, to usize: v[i(my_u8_index)] This could be implemented as a compile-time check, with no runtime errors. You'd have to limit which types you support as indices if you want to be portable to platforms with tiny pointers, of course. I guess something like this might be useful inside of specialized library code that worked with lots of small vectors. But in general, Rust heavily favors explicit over implicit in many areas. If you want lots of automatic implicit behavior, something like Scala might be a better choice?
- samhw 5y ago
  If you were going to do that, it may be easier just to implement `Index`/`IndexMut` over `u8`/`u16`/.. for whatever type (newtype if necessary) you're indexing into. I suppose it's hard to say without context though.
bestouff 5y ago
You could use TiVec[1], TiSlice[1] or TiBitset[2] (shameless plug) to have datastructures indexed by the type you need, all checked at compile type. All you need is a From/Into implementation for your chosen index type. 1: https://lib.rs/crates/typed-index-collections https://lib.rs/crates/typed-index-collections 2: https://lib.rs/crates/tibitset https://lib.rs/crates/tibitset
ATsch 5y ago
> Using a usize often seems wasteful for indexing into small arrays and slices The opposite is often the case, as the architecture may not support offsetting a pointer by those sizes, requiring lots of casting in tight loops. Making that explicit makes the programmer aware of this. This is one major reason that C compiler developers want all overflow to be undefined behavior, as it allows them to upgrade for loops that use smaller index types to larger ones.
- staticassertion 5y ago
  That seems easy to optimize out, especially given rust's mutability guarantees. If I have a u8 and I index into an array in a loop the compiler should be free to cast it to a usize above that loop, right? The benefit being you can store much smaller structures, plus in the case of memory unsafety you reduce attacker control. The vast majority of strings I personally use are certainly well under 2^32 bytes, and most are probably under 2^8.
mjw1007 5y ago
Right, better control of the index type can help you say what you mean, and help the typechecker catch more mistakes. If I have an array representing a single-byte lookup table, it would be nice if I could say that the array's type is array-indexed-by-u8 rather than array-indexed-by-usize. Ada did this well: it even lets you declare an array whose index is some enumerated type.
- Ar-Curunir 5y ago
  > _ it even lets you declare an array whose index is some enumerated type._ You can do this in Rust also: make a custom newtype wrapper for your array, and impl Index<CustomEnum> for the wrapped array.

Ygg2 5y ago

Rust supports u16 pointer. Suddenly you are casting u32 to u16. And fun begins.

davidhyde 5y ago
Exactly this!

benschulz 5y ago

IIRC integer literals are the blocking issue here. Bounds checking (and elision) happens anyway, but when `Index<T>` is implemented for multiple integer types, `foo[0]` becomes ambiguous.

pwdisswordfish9 5y ago

What’s wrong with .try_into::<usize>().unwrap()?

ekhjarta 5y ago
It fails at runtime and not at compile time and it only fails if the value is out of range, so you have to test with large enough values to trigger the assertion during testing. We want to be able to index with integer types that are smaller than or has the same size as usize, but not with integer types that are larger than usize. And we want those checks at compile time.
- dgb23 5y ago
  Unwrap isn’t an evil thing to avoid completely. The type system cannot understand all invariants, but you can, and you can make sure they are correctly implemented.
  - deleted 5y ago
    [deleted]
masklinn 5y ago
.into() will work for u8 and u16, as rust assumes >= 16b pointers.
- est31 5y ago
  Which totally makes sense. u8 means 256 bytes of addressable memory. You might design chips with such limited memory, but maybe high level (read non assembly) languages are not the right tool for targetting them.
edflsafoiewq 5y ago
It's hideous.

dgb23 5y ago

Code looks ugly should maybe not be a big concern in a language like Rust. It’s fundamentally ugly to begin with in many ways. And I think that’s fine because it is a language that is primarily about control. One could argue that this is beautiful in its own way. There’s a clarity and power in being explicit while the constraints let you move on with confidence.

scns 5y ago
Function over form. I think it makes a lot of sense in Rusts' domain.

ekidd 5y ago

Rust really doesn't do implicit numeric conversion, and I suspect it would be hard to retrofit. But you could write a function i(...) that promoted u8, etc, to usize: v[i(my_u8_index)] This could be implemented as a compile-time check, with no runtime errors. You'd have to limit which types you support as indices if you want to be portable to platforms with tiny pointers, of course. I guess something like this might be useful inside of specialized library code that worked with lots of small vectors. But in general, Rust heavily favors explicit over implicit in many areas. If you want lots of automatic implicit behavior, something like Scala might be a better choice?

samhw 5y ago
If you were going to do that, it may be easier just to implement `Index`/`IndexMut` over `u8`/`u16`/.. for whatever type (newtype if necessary) you're indexing into. I suppose it's hard to say without context though.

bestouff 5y ago

You could use TiVec[1], TiSlice[1] or TiBitset[2] (shameless plug) to have datastructures indexed by the type you need, all checked at compile type. All you need is a From/Into implementation for your chosen index type. 1: https://lib.rs/crates/typed-index-collections https://lib.rs/crates/typed-index-collections 2: https://lib.rs/crates/tibitset https://lib.rs/crates/tibitset

ATsch 5y ago

> Using a usize often seems wasteful for indexing into small arrays and slices The opposite is often the case, as the architecture may not support offsetting a pointer by those sizes, requiring lots of casting in tight loops. Making that explicit makes the programmer aware of this. This is one major reason that C compiler developers want all overflow to be undefined behavior, as it allows them to upgrade for loops that use smaller index types to larger ones.

staticassertion 5y ago
That seems easy to optimize out, especially given rust's mutability guarantees. If I have a u8 and I index into an array in a loop the compiler should be free to cast it to a usize above that loop, right? The benefit being you can store much smaller structures, plus in the case of memory unsafety you reduce attacker control. The vast majority of strings I personally use are certainly well under 2^32 bytes, and most are probably under 2^8.

mjw1007 5y ago

Right, better control of the index type can help you say what you mean, and help the typechecker catch more mistakes. If I have an array representing a single-byte lookup table, it would be nice if I could say that the array's type is array-indexed-by-u8 rather than array-indexed-by-usize. Ada did this well: it even lets you declare an array whose index is some enumerated type.

Ar-Curunir 5y ago
> _ it even lets you declare an array whose index is some enumerated type._ You can do this in Rust also: make a custom newtype wrapper for your array, and impl Index<CustomEnum> for the wrapped array.