Post #1743736
2025-11-19 07:33 UTC
Replies (19)
-
@Mara@hachyderm.io 2025-11-19 07:36
(That the name "or_panic" would have been better isn't much of a hot take, but adding "or_panic()" now and deprecating "unwrap()" would likely be controversial.)
-
@froge@social.glitched.systems 2025-11-19 07:35
@Mara@hachyderm.io this is doubly confusing because in many other languages, even some FP languages, "unwrapping" a value is actually a non-panicing operation lol
-
@druskus@chaos.social 2025-11-19 07:37
@Mara@hachyderm.io i remember when learning rust a long time ago this was a bit confusing. expect(), vs unwrap(), vs panic!() vs all the *_or_default(), *_or()...
-
@agnew_hawk@mastodon.social 2025-11-19 07:37
@Mara@hachyderm.io Doesn't help that I'm associating unwrapping with unwrapping presents, and occasionally expecting what's inside. Like a perpetual birthday party.
-
@bugaevc@floss.social 2025-11-19 07:37
@Mara@hachyderm.io yes please! 💯 I had a design where the || and && operators were overloadable, and there, res.unwrap() turned into res || panic!() and res.unwrap_or(default_value) into res || default_value and res.unwrap_or_else(callback) into res || callback() But if you're not doing that, renaming the methods would be great.
-
@soph@grrl.me 2025-11-19 07:49
@Mara@hachyderm.io seconded
-
@ygor@floss.social 2025-11-19 08:16
@Mara@hachyderm.io But wouldn't that make the API inconsistent? Since the other or*() methods don't change the type. I guess there are quite a few Rust methods with innocent sounding names that can panic. clamp() is one I'm always wary of. There's also the ones that allocate memory, like for Vec and String. #RustLang
-
@balasubramanium@social.linux.pizza 2025-11-19 08:17
@Mara@hachyderm.io how аbout using а much stable language like c++ instead of rust
-
@ximon18@fosstodon.org 2025-11-19 08:38
@Mara@hachyderm.io Funny timing as I actually came across an unwrap_or() in code yesterday and it took me a few seconds to realize it wasn’t going to panic, really not helpful naming.
-
@timClicks@mastodon.nz 2025-11-19 08:58
@Mara@hachyderm.io Quite a good suggestion. It makes panicking an intentional outcome rather than an accidental one. FWIW I don't know if many people liked unwrap(), but they really didn't like Aaron Turon's suggestion of assert()
-
@tauon@possum.city 2025-11-19 09:29
@Mara@hachyderm.io yeah. the actual thing it does is more like unwrap_or_panic, this is a good idea
-
@azymohliad@fosstodon.org 2025-11-19 09:45
@Mara@hachyderm.io this sounds much more descriptive! But how would it play with the existing .or() and .or_else(), which return another Option/Result? If those didn't exist, then renaming all .unwrap_or_*() to .or_*() would make it all nice and consistent. But those are taken, and keeping .unwrap_or_*() alongside .or_panic() seems to introduce a new inconsistency 🤔
-
@twinkle@sweet.succubi.services 2025-11-19 09:47
@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
-
@zimzat@mastodon.social 2025-11-19 10:09
@Mara@hachyderm.io I think it's a fantastic idea. I would also love to see it not encouraged by practically every tutorial out there, especially official ones, as it creates a bad habit that has to be unlearned.
-
@thibault@mastodon.online 2025-11-19 10:18
@Mara@hachyderm.io The naming of "expect" was the worst offender for me. For the few times I use rust, I always forget how its called. I dont expect a function named `expect` to take an error message as input, but rather to evaluate a predicate on the object (think of `32.expect(is_even)`). Naming it `or_panic` would make much more sense.
-
@cehteh@karlsruhe-social.de 2025-11-19 11:50
@Mara@hachyderm.io I'd even be in favor of .or_abort(), having panic=abort a build configuration and not an API is a misfeature imo (of course .or_panic() could stay as well)
-
@DrRac27@fosstodon.org 2025-11-19 12:13
@Mara@hachyderm.io I think this would absolutely be doable and a good idea. I would just prefer `unwrap_or_panic()` and `unwrap_or_panic_with(msg)` instead. Especially `expect(msg)` is just a bad name in my opinion. `unwrap()` sounds a bit too harmless but `expect()` really makes no sense to me. But I think a clippy lint is enough and it could be an alias for a really long time to not break things.
-
@GerhardD@olching.social 2025-11-19 12:48
@Mara@hachyderm.io I don't agree. "unwrap()" suggests, there *should* be something inside, a Result or an Option. "or_panic()" does not.
-
@blossomanytime@mastodon.social 2025-11-19 13:53
@Mara@hachyderm.io I feel like unwrap is mostly useful while developing/prototyping, so you can get stuff done quickly in that phase. Maybe the compiler could have a "dev mode" flag that lets you use Results directly without .unwrap()ping, saving a few keystrokes, and then you can go clean up those places later when you are done with the "rapid" phase.