Hacker News Reader

Comment by pjmlp | Hacker News Reader

C programmers are well known to refer to such programming safety as straighjacket since the Pascal days anyway.

There was more than enough time to learn why it was the right option to start with.

Rust does go overboard though, e.g. indexing requires `usize`. You either use `usize` for all your integers, or you end up with a cast-salad.

   arr[i as usize]

This is actually risky, because even when you only meant to extend, you can also accidentally truncate or change sign. `as` does all of these things without a warning, and mixed with type inference it can easily lead to surprises.

Rust makes it worse by insisting on a theoretical support for 16-bit and 128-bit `usize` regardless of the target platform, so you can't use `a[i.into()]` to infallibly convert `u32` to `usize` on 32-bit and 64-bit platforms.

The correct syntax is:

   arr[usize::try_from(i).unwrap()]

which is painfully verbose. In larger expressions it's almost an obfuscation of what the code is actually doing.

The Rust approach of having all indexing being unsigned has been extremely annoying for programming algorithms which need to do interesting indexing patterns like walking backwards through an array while indexing into another: the fact that “i >= 0” can no longer be used as a loop condition is quite exasperating. It means other more complicated indexing or looping approaches need to be used, and when showing code to coworkers (mostly mathematicians), they puzzle over this for a while before asking “why not just use i >= 0”? It’s not just this case - doing index arithmetic in general is vastly complicated by the fact that it’s difficult to detect idx < 0.

I think unsignedness on array indices is one of those places where the “make invalid states unrepresentable” mantra has gone too far: yes it’s nice that theoretically the whole 64-bit index space is addressable from a byte array based at 0, but in reality -1 is just as stupid and invalid an array index as 2^64 - 1 for pretty much every use-case. What we gain is negligible; what we lose is a lot of sensible code for dealing with index arithmetic.

negative indexing could even make sense in some situations. It's not at a far stretch to imagine a pointer pointing to the one-past-last element of a series, and use e.g. -1 to get the most recent element. Python's indexing indeed works like that way.

I'm not a Rust programmer, but AFAIK Rust has inline functions, so if your code has lots of indexing calls, could most of the pain go away with a few short helper functions?

    #[inline(always)]
    fn idx(i : u32) { usize::try_from(i).unwrap() }

    #[inline(always)]
    fn get(arr: [T], i : u32) { arr.[usize::try_from(i).unwrap()] }

Have to repeat the definition for each numeric type you use, I guess, but hopefully you aren't using _that_ many of them.

As I'm sure you're aware, this gets lost in bike shed land every time it comes up but Rust could implement `Index<iN|uN>` pretty easily. Unlike C you don't need an implicit cast to do the right thing.

Personally, I have datastructure that uses non `usize` indexes I usually wrap my vector/array in in a custom type that implements index on whatever my common index types are.

It's not only "bikeshedding", there are (in my understanding) significant inference issues that happen if we were to enable this, and that would have to be dealt with in a satisfactory way.

Just wait for the updated C++ standard with size_t indexers.

The straight-jacket is the syntax in Ada. I don't feel locked in by the correctness measures, but if you are going to have elaborate declaration blocks I prefer "let foo = bar in ...".

Because everything else is "let" in disguise. ML got the syntax right.

Reply on news.ycombinator.com