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.