Stream: ideas

Topic: panic on out-of-bounds

Richard Feldman (Apr 16 2022 at 16:25):

so today we have List.get : List elem, Nat -> Result elem [ OutOfBounds ]*

what if instead if was List.get : List elem, Nat -> elem and it gave a panic if the index was out of bounds? (And then we had List.getChecked with today's signature, similar to how Num.add panics by default but you can opt into Num.addChecked which returns a Result in case of overflow.)

context:

• Specifically when I'm doing indexed lookups into an array, I'm struggling to think of a time when having it return a wrapped type helped me out. I think almost always I'd do the equivalent of Result.withDefault 0, which is arguably _more_ error-prone because if I made a mistake, I don't get a big obvious error, but rather a subtler incorrect value that I might not even notice.
• This is how a lot of languages do it, and while I see NullPointerExceptions from those languages all the time, I don't remember seeing out of bounds exceptions coming up in production on a regular basis. In development and testing, sure, but outside of production they're actually pretty helpful (especially if they come with a stack trace) as a way to very quickly tell where you messed up.
• The panic version compiles to fewer instructions in a loop, so there's a performance benefit to that being the default.

thoughts?

Folkert de Vries (Apr 16 2022 at 16:30):

I'd prefer to swap the names here, so get is the safe one, getUnchecked is the unsafe one (but more typing)

Folkert de Vries (Apr 16 2022 at 16:31):

you shall pay for your unsafety with entering more characters

Brendan Hansknecht (Apr 16 2022 at 16:32):

A lot of my code would greatly appreciate that

Jared Cone (Apr 16 2022 at 16:32):

The stuff in Num is going to follow the other pattern tho? Default panics, but there are Checked versions that return Result

Brendan Hansknecht (Apr 16 2022 at 16:36):

I personally feel ok with that cause I think the safety expectation is different here, but I can see the annoyance with inconsistency.

Kevin Gillette (Apr 16 2022 at 16:48):

I've never really had a problem with Elm's use of Maybe for List.head (I've also been somewhat annoyed by Haskell's lack of Maybe for the same function).

I see two cases:

1. Cases in which it's purely the programmer's fault (such as a buggy edge case in an algorithm). These can panic, since it's not clear what the algorithm should do if the algorithm itself has a bug.
2. Cases in which there's some static data-set being referenced, and the index comes from an untrusted source (user input). Yes, the programmer could use an if to check bounds, and if valid, call the possibly-panicking List.get, but bounds checking itself is error prone, and ideally we should provide a List.getChecked for such cases.

Richard Feldman (Apr 16 2022 at 17:12):

what if it was get and getOrCrash?

Richard Feldman (Apr 16 2022 at 17:13):

(I don't think of it as "unchecked" because there's still a check; it's just that the check panics instead of returning Err)

Brendan Hansknecht (Apr 16 2022 at 17:16):

OrPanic?

Richard Feldman (Apr 16 2022 at 17:17):

either way

Richard Feldman (Apr 16 2022 at 17:17):

separately, I'm kinda liking the name "crash" over "panic" now that we're finding more situations where it seems like a better design

Richard Feldman (Apr 16 2022 at 17:17):

just to emphasize like "this is not recoverable, this should only be used when you want the program to crash"

Richard Feldman (Apr 16 2022 at 17:19):

but yeah, that seems reasonable

Brendan Hansknecht (Apr 16 2022 at 17:22):

I feel like renaming panic is a separate ordeal, but sure. Crash just feels like a lie to me since the host can recover/keep running

Richard Feldman (Apr 16 2022 at 17:23):

to be fair, when Erlang says "let it crash" they mean an operation that does get recovered higher up the chain :big_smile:

Brendan Hansknecht (Apr 16 2022 at 17:28):

Sure but they have separate virtual processes and a very different mental model of systems

Kevin Gillette (Apr 16 2022 at 17:31):

How common is that interpretation of crash?

Kevin Gillette (Apr 16 2022 at 17:32):

is it more that "crash" in Erlang doesn't mean crash, or that Erlang programmers would say "oh, it definitely crashed, but our platform is unusual in that it catches crashes" ?

Brendan Hansknecht (Apr 16 2022 at 18:42):

I think in Erlang it would be "it definitely crashed, but it has a parent process that relaunched it after the failure"

Richard Feldman (Apr 16 2022 at 18:46):

yeah it's like "the process crashed" - which I kinda think fits here

Richard Feldman (Apr 16 2022 at 18:46):

like "the application crashed" but the platform didn't

Richard Feldman (Apr 16 2022 at 18:46):

partly I think that panic doesn't have sufficiently negative connotations - like I look at how it's used in Rust, and it seems more common than I'd like it to be used in Roc

Richard Feldman (Apr 16 2022 at 18:47):

"just have it panic" seems like a pretty casually done thing in Rust, whereas "just have it crash" sets off more red flags for me just from the way it sounds (which I think is good!)

Brendan Hansknecht (Apr 16 2022 at 19:08):

I think rust's big issue is not panic but things like unwrap and expect. It is common to just write off error/edge cases and assume they won't happen, or if they do happen it will be something to figure out then. I think a lot of the panics exists because people think they will deal with it properly later if it ends up being an issue. So i don't think it is a panic issue but all of the wrappers and convenience

Last updated: Jun 16 2026 at 16:19 UTC