You obviously can, but indexing with `[]` is the default way one would think of doing and it can certainly be surprising that it panics.

Besides, the slice API is full of "infallible" functions that panic when given bad parameters - just search for "Panics" in https://doc.rust-lang.org/stable/std/primitive.slice.html - because it's expected that it would be more annoying for people to deal with the fallibility (like having to manually `.expect()` or bubble up the error) when they "know" that it wouldn't fail.

"Infallible" is not a term that the Rust library docs use, to my knowledge. You'll note that none of the panicking APIs on that page claim to be infallible, only memory safe.

(I happen to think Rust can and ought to substantially improve the ergonomics of infallible API design, as well as provide more compiler support for avoiding fallible dependencies. But it's unreasonable to treat fallibility as a deficit, since it's explicitly outside of Rust's safety model.)

I put "infallible" in quotes because a fallible API would be one that returns Option / Result where the None / Err encodes the failure. So on the surface these API look like they can't fail, except of course they do, by panicking.

I understand the fallible/infallible distinction. My point was that the concept of fallibility/infallibility is not encoded into Rust's semantics: any function, even an "infallible" one, can panic (e.g. on stack overflow or an underlying memory allocation error).

(I think we're in agreement about fallible APIs being confusing and a footgun.)

Rust has an entire type named Infallible.

https://doc.rust-lang.org/core/convert/enum.Infallible.html

Infallible is the type of errors which can't happen. It will some day be a synonym for ! (aka Never, the type of return and break and such things) but even today it's an Empty Type.

Empty Types are in some sense even smaller than the Zero Size Types like the empty tuple. The ZSTs have a value, it's just always the same value and so it needn't be stored anywhere. The Empty Types don't even have a value. So not only do you not need anywhere to store their value, you don't even emit code to handle this value. Generic error handling code evaporates at compile time for Infallible.

Right, but that's a subtly different type of infallibility: it allows the compiler to optimize instantiations of traits that are generic over error types by establishing that the error is impossible in a concrete implementation.

The other kind of infallibility is "the absence of an error encoding for a function means the function cannot fail". The Infallible type can't provide that, since a function have an infallible `Err` case but still arbitrarily decide to panic at runtime.

Edit: in other words, Rust's type system isn't strong enough to encode "full" infallibility. We'd need some kind of effect typing for that.

> You obviously can, but indexing with `[]` is the default way one would think of doing and it can certainly be surprising that it panics.

True. I think it would've been nicer to make it return an Option type, but I guess performance would suffer if they made everything consistent.

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.

It would be neat if the language grew panic annotations.

It would be nice to know shallowly if something could panic. It'd also be amenable to all sorts of tooling.