5 ms·

let _ = v[0]; // panics Why don't you use .get() instead?

by HKH2 4y ago

Arnavion 4y ago
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 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.
- woodruffw 4y ago
  "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.)
  - Arnavion 4y ago
    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.
    - woodruffw 4y ago
      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.)
  - tialaramex 4y ago
    Rust has an entire type named Infallible. https://doc.rust-lang.org/core/convert/enum.Infallible.html 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.
    - woodruffw 4y ago
      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.
- HKH2 4y ago
  > 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.
  - junon 4y ago
    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.
    - Arnavion 4y ago
      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.
      - junon 4y ago
        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.
        Arnavion 4y ago
        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.
echelon 4y ago
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.

let _ = v[0]; // panics Why don't you use .get() instead?

by HKH2 4y ago

let _ = v[0]; // panics Why don't you use .get() instead?

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 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.

woodruffw 4y ago
"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.)
- Arnavion 4y ago
  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.
  - woodruffw 4y ago
    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.)
- tialaramex 4y ago
  Rust has an entire type named Infallible. https://doc.rust-lang.org/core/convert/enum.Infallible.html 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.
  - woodruffw 4y ago
    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.
HKH2 4y ago
> 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.
- junon 4y ago
  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.
  - Arnavion 4y ago
    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.
    - junon 4y ago
      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.
      - Arnavion 4y ago
        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.

echelon 4y ago

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.