3 ms·

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 situati

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?

ArrayBoundCheck 4y ago
> 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
- throwaway17_17 4y ago
  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.
gpm 4y ago
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.
- throwaway17_17 4y ago
  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.
  - TheDong 4y ago
    You're right that '[i]' is just a function call ('.index(i)' https://doc.rust-lang.org/std/ops/trait.Index.html 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.
    - ArrayBoundCheck 4y ago

ArrayBoundCheck 4y ago

> 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

throwaway17_17 4y ago
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.

gpm 4y ago

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.

throwaway17_17 4y ago
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.
- TheDong 4y ago
  You're right that '[i]' is just a function call ('.index(i)' https://doc.rust-lang.org/std/ops/trait.Index.html 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.
  - ArrayBoundCheck 4y ago