It's opt in, like most things in rust. Any time you have an option, you can simply unwrap it to say "I'm asserting I know this is a 'some' value, and if it's perhaps not, then please panic". Forcing an unwrap in every single case would indeed kill performance.

No. There would be no difference in performance if it returned an Option and required the caller to unwrap. That's what `[]` is doing internally anyway. As are all the other functions I linked that are documented as panicking - they're doing tests manually and `panic!()`'ing if those tests fail anyway.

As I said in the original comment, the reason these functions panic is that the common case for them is where the caller is using parameters that ought to be valid already (either hard-coded or already checked). So it would be less ergonomic to require the callers to handle an error that they know won't happen.

If the compiler wasn't able to make optimizations then you're right. But it can, especially when it can determine the bounds checks are unnecessary.

And those optimizations apply regardless of whether the function checks the parameter internally and panics on failure, or if you check the parameter before calling the function and unwrap the function result. Again, there is no difference. There's really no need to argue about this. Feel free to godbolt it.

You're right.

https://godbolt.org/z/cfr8MEG6j https://godbolt.org/z/7crr4n66Y

I suppose I'm used to C/C++ compilers not going as far down the optimization rabbit hole as Rust seems to, where they often miss more complex optimizations like this in sufficiently advanced wrapper types etc.