Richard Feldman (Jan 29 2024 at 20:24): Richard Feldman (Jan 29 2024 at 20:24):following up on #beginners > this should never happen - what if we had this?
Result.orElse : Result ok err, (err -> ok) -> ok
then you could do:
|> Result.orElse \_ -> crash "blah"
what I like about this compared to a function like unwrap (which I'm explicitly opposed to ever adding to Result) is that you still have the crash keyword explicitly in your code, so you can see that a crash is possible here. It would just be more pipeline-friendly than having to write out the when.
Brendan Hansknecht (Jan 29 2024 at 20:28):I like that a lot. Then people can stop writing unwrap helpers and still have something explicit inline.
Isaac Van Doren (Jan 29 2024 at 21:05):That sounds great
Kiryl Dziamura (Jan 29 2024 at 21:06):
unwrap
There’s also expect in rust’s Result
It would be great to have smth like either of that at your fingertips. The very first thing I implemented in roc is listGetUnsafe (don’t know why it wasn’t the unwrap)
Agus Zubiaga (Jan 29 2024 at 21:15):What if crash could print anything with Inspect like dbg? Then you could do:
|> Result.orElse crash
You’d get the error printed and a stack trace
Richard Feldman (Jan 29 2024 at 22:33):hm I'd say let's try it as-is and revisit that later :big_smile:
Andrew C (Feb 03 2024 at 12:50):Am I right in assuming that you can't put crash in library code or pure roc or something, it's not like haskell's fail wherever you like error? I just don't want orElse, crash to be the roc "how do I get rid of result?"
Anton (Feb 03 2024 at 12:57):Am I right in assuming that you can't put crash in library code
It's something we've discussed in the past but it is still allowed now.
Last updated: Jun 16 2026 at 16:19 UTC