Could you please stop drawing incorrect conclusions, and perhaps ask first?
What gave you that impression that my only goal is to report a problem?
I asked the question here in order to raise my concern about the current behavior and perhaps learn why is so. Never I indicated that I as my only goal have reporting a problem.
Thank you for that clarification. I somehow missed it (just now went through all my replies to admire the logic and rhetoric applied and I found your answer :). Thanks.
Btw, would you know how to distinguish true compilation error from those caused by linting?
It's actually slightly less trivial than one might hope, but the telltale sign is, e. g. looking a the error produced by the example in the 3rd post in this thread
error: this operation will panic at runtime
--> src/main.rs:7:17
|
7 | let arr_v = arr_0[11];//Doesn't compile
| ^^^^^^^^^ index out of bounds: the length is 10 but the index is 11
|
= note: `#[deny(unconditional_panic)]` on by default
the note: `#[deny(unconditional_panic)]` on by default part is what's telling you that this error is actually just a deny by default lint, not a hard error. This note will, AFAIR, also only fire once for each category of lint, so if there's multiple unconditional_panic errors only one will contain this note - but even in that case, hopefully all of them will share a similar or maybe even the same error message "this operation will panic at runtime", so you can still identify them.
Thanks!
Note that researchers are interested in the sort of compilers that can do this analysis - where they evaluate your program at compile time to the point where running the program does the minimum amount of work possible.
But this has been a research topic since (at least) the late 1960s, and the fact that we don't routinely use such compilers is an indication of how practical they are.
If that is true, then why are you suggesting people are willing to sacrifice memory safety, right there in the quoted text?
I am willing to believe you may have been confused. Accessing beyond array bounds in Rust is not memory unsafe and not UB. It is prevented at runtime via a panic. In some cases the compiler can see when this would happen, but in the general case the runtime check is the best that can be achieved.
Nitpick: indexing is prevented. One might go for a raw pointers and offset them into the unallocated memory directly - in that case, of course, all bets are off, but, well, that's raw pointers for you.
Sure. I think it goes without saying that using pointers in unsafe code can cause memory unsafety.
Array indexing is never that.
That's not an answer. I understand perfectly well your replies, but it's becoming increasngly clear you do not.
I'd really prefer that we stay charitable here. There is obviously a valid issue with the compiler, we're just talking past each other regarding its consequences.
I'm afraid that I'm still having trouble understanding what you were trying to say. There are a few possible ways to handle out-of-bounds indices:
array.get_unchecked(i) and array.get_unchecked_mut(i).&array[i] and &mut array[i]. If i is a literal value, then the compiler has some code to output a helpful lint if this would unconditionally reach a panic. But this lint is somewhat inconsistent, and it will err on the side of not firing, since making it guaranteed to fire would require evaluating arbitrary constant expressions in the general case.&array[index!(i)] and &mut array[index!(i)], using my macro from earlier.[1] This has the downside that i must be a compile-time constant. Perhaps it would be helpful to add a similar API for infallible constant array indexing in the future.Thus, when I say that extending the lint comes at a cost of compile time, I mean to say that it's already correct for indexing expressions &array[i] and &mut array[i] to panic at runtime, so it wouldn't make much sense for the compiler to perform an arbitrary amount of work to determine whether the panic is unconditional. Instead, if hard compile-time guarantees are what we want, then we should add them to a new const-based API, instead of overloading the existing panicking API. The unsafe, unchecked API can still exist on its own, indepentent from the panicking vs. const checking APIs.
It would probably be more practical to define an extension trait on [T; N] with a fn const_get<const I: usize>(&self) -> &T and fn const_get_mut<const I: usize>(&mut self) -> &mut T. But that would have the downside that every such error would be a post-mono error, whereas the macro solution could be modified to cause an pre-mono error if const {} blocks are stabilized. ↩︎
That's well and good, although to me the OP's posts show both a lack of understanding and a needlessly combative attitude. I'll gladly leave you to it. You definitely have more patience than I. 
Just because you don't like it it doesn't make it invalid answer.
But lets try differently:
Is access out of bounds considered unsafe?
This topic is temporarily closed for at least 4 hours due to a large number of community flags.
I don't see any productive discussion here anymore, so it's time to close the (already automatically temporarily closed) thread permanently.