News for hackers. Stuff that matters.
Re:2 years of fiddling with Rust – critical thoughts by Arnavion on Monday November 07, 2022 @11:39AM (#33508168)
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.

Re:2 years of fiddling with Rust – critical thoughts by junon on Monday November 07, 2022 @08:26PM (#33514910)
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.
Re:2 years of fiddling with Rust – critical thoughts by Arnavion on Tuesday November 08, 2022 @02:20AM (#33516716)
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.
Re:2 years of fiddling with Rust – critical thoughts by junon on Thursday November 10, 2022 @03:08AM (#33543597)
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.