Hacker News Reader

Comment by throwaway17_17 | Hacker News Reader

I was under the impression that unless inside an unsafe block, Rust required/automatically-placed bounds checks on array accesses. The out there was for situations where the compiler could 'prove' that the index was within bounds statically. But maybe I was wrong about that.

With such a strong focus on bounds checking, are there any 'systems programming' languages that you do find acceptable?

View on HN

Even in unsafe blocks, rust automatically places bounds checks on array accesses. It's just that in unsafe blocks you get access to additional more verbose functions, such as "array.get_unchecked(idx)" instead of "array[i]", that don't perform bounds checks.

Unsafe blocks don't change the semantics of code, they just let you write code you couldn't write outside of them.

That's interesting, I don't know that I would have thought about the behavior of the subscript operator as a semantic issue in that way. I guess it is a different view point to mine. I, nearly, universally view the subscript operator as a function that takes a Nat and produces the element of the array/list/etc that is stored at that index. So, for me, the placing of bounds checks when using that function is an implementation detail and therefore, if unsafe removes it, it does not effect the semantics.

You're right that '[i]' is just a function call ('.index(i)' https://doc.rust-lang.org/std/ops/trait.Index.html).

> So, for me, the placing of bounds checks when using that function is an implementation detail and therefore, if unsafe removes it, it does not effect the semantics.

The function is not marked as unsafe, so it promises that it will not corrupt memory and thus must perform bound checks. The designation of safe/unsafe for a function is compile-time and promises certain semantics.

It would be a semantic issue for a safe function to invoke unsafe behavior.

Even within an 'unsafe' block, calling safe functions should not cause memory corruption as long as your other unsafe calls / unsafe code didn't do anything "wrong".

Anyway, to implement a function like that, you'd need:

    fn index(i) -> T {
        if is_caller_in_unsafe_block() {
            return unsafe { unsafe_index(i) }
        } ...
    }

The compiler does not, as far as I'm aware, have any "is_caller_in_unsafe_block" primitive, and adding one seems quite fraught.

> automatically-placed bounds checks on array accesses

That's exactly why I get annoyed. How will it be fast if it branches on every access

> where the compiler could 'prove'

The compiler doesn't prove shit. It lets the optimizer do it. It's extremely easy to fool the optimizer

> there any 'systems programming' languages

The ones that don't make false claims (so not v or rust) and don't insert code I don't want

Your objection to saying my saying "the compiler could 'prove'" is one of the reasons I put the quotes around prove. Also, thanks for answering, I didn't want my question to seem like baiting or trying to start a string of downvotes, etc. I am honestly interested developer stances on languages, for whatever reason those stances exist.

Reply on news.ycombinator.com