3 ms·

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 differe

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