@twinkle@sweet.succubi.services
Post #2227748
2025-11-19 09:47 UTC
@Mara@hachyderm.io i think it’s a valid take, but counterargument:
say you have a function called parse_input that returns an Option
and we have a part of the code where parse_input is presumed to be infallible, perhaps we’re loading a static file at compile time
doing let parsed = parse_input(MY_STATIC_INPUT).or_panic(), at least to me, feels worse than saying “unwrap” (because we’re expecting a value to be returned here, the focus is the returned value, not the fallibility)
unwrap is what the operation means, but it’s not what the operation is (which is to panic), and you can see i did a cheek-in-tongue argument for expect too (which ties into how you’re “supposed” to format the message, i. e. a “correct” expect reason here might be should be infallible with MY_STATIC_INPUT)
the case is stronger for Result though
Replies (2)
-
@twinkle@sweet.succubi.services 2025-11-19 09:54
@Mara@hachyderm.io though for expect the case to keep it as-is is doubly strong because of how they end up being shown in a panic message (something something expect isn’t just panicking with the message provided, and my crackpot theory is that they chose the name so people go look up why it’s called expect and learn the reasoning)
-
@bob_zim@infosec.exchange 2025-11-19 14:19
@twinkle@sweet.succubi.services @Mara@hachyderm.io To me, this is where “or_panic()” makes the most sense. When I have something which shouldn’t be able to fail and it fails anyway, I want the application to panic because it’s clearly in an unreasonable state.