3 ms·

Nope. But people are thoroughly confused by it. Comes up all of the time. And a lot of people have more extremist positions. Banning unwrap. Or banning any pani

Nope. But people are thoroughly confused by it. Comes up all of the time. And a lot of people have more extremist positions. Banning unwrap. Or banning any panicking branches at all. That's why my blog post covers an example where we convert a function that never panics (sensible) to a function whose signature says it might return an error, but it actually will never return an error (bonkers). People advocate for this. After publishing this article, it almost seems like people are more confused than I thought. Idk. Anyway, no, this blog is not meant to be controversial. It is meant to untangle knots.

wokwokwok 4y ago
Maybe people didn’t read all the way to the end of your article? I mean, my gut feel response was to the first half was, this is crazy talk. Look, given an api that when I call it, it either a) panics or b) returns an error, I’m pretty clear on which one I prefer in general. …but the point (or what I got out of it anyway, by the end) isn't “It’s fine to panic”. It’s not fine to panic arbitrarily. Code should not panic generally speaking. …but there are also times when it a unavoidable, or pointlessly pedantic (eg. Slice index, FSM example) to avoid it completely. I certainly started reading the top section (aka “Therefore, when runtime invariants arise…”) and my response was: yes, but most of the time you don’t have those. …and if you don’t, why would you use unwrap? I can say, at least, you made me have a good think about it.
- burntsushi 4y ago
  Glad you got a good think. One thing worth pointing out, is that I did try to head off an experience like what you had by stating my position up front. In the first section after the ToC, the third bullet point reads: > If a Rust program panics, then it signals a bug in the program. That is, correct Rust programs don’t panic. I suspect you might have just accidentally skipped over that. Because I think it re-affirms that you should indeed not panic arbitrarily. As for runtime invariants, I have them a lot in Rust. I tend to work on lower level text primitives (regex engines) where perf is quite important. Perf tends to add complexity in the form of an increased number of runtime invariants. I do my best to push them to compile time where I can, but it just isn't always possible.

wokwokwok 4y ago

Maybe people didn’t read all the way to the end of your article? I mean, my gut feel response was to the first half was, this is crazy talk. Look, given an api that when I call it, it either a) panics or b) returns an error, I’m pretty clear on which one I prefer in general. …but the point (or what I got out of it anyway, by the end) isn't “It’s fine to panic”. It’s not fine to panic arbitrarily. Code should not panic generally speaking. …but there are also times when it a unavoidable, or pointlessly pedantic (eg. Slice index, FSM example) to avoid it completely. I certainly started reading the top section (aka “Therefore, when runtime invariants arise…”) and my response was: yes, but most of the time you don’t have those. …and if you don’t, why would you use unwrap? I can say, at least, you made me have a good think about it.

burntsushi 4y ago
Glad you got a good think. One thing worth pointing out, is that I did try to head off an experience like what you had by stating my position up front. In the first section after the ToC, the third bullet point reads: > If a Rust program panics, then it signals a bug in the program. That is, correct Rust programs don’t panic. I suspect you might have just accidentally skipped over that. Because I think it re-affirms that you should indeed not panic arbitrarily. As for runtime invariants, I have them a lot in Rust. I tend to work on lower level text primitives (regex engines) where perf is quite important. Perf tends to add complexity in the form of an increased number of runtime invariants. I do my best to push them to compile time where I can, but it just isn't always possible.