I like more specificity in why the "unwrap" is there, but I think there is something missing here. Some have mentioned the desire to fail loudly but without stopping the entire application, so it might be good to have variant that make as much noise as possible without crashing (possibly allowing the developer to overwrite how/where to log/send that) and fall back to a default value. It's already possible to do that, but requires more boilerplate (e.g. let else):
- Bikesheddable:
.expect_fallback(custom message", value_to_use_if_it_failed)
Currently we have unwrap_or and unwrap_or_default, but they fail completely silently, which is sometimes not what you want.
I'm not sure how much that'd actually be used in practice, but I suspect it's more likely to be used than a multi-line error handling and there are some situations where failing with a panic is way worse than continuing with not-quite-correct data (hence why unwrap_or exists), but if you want it to make a noise you currently need something like this:
foo.map_err(|_| println!(...)).unwrap_or(0)
Though arguably that wouldn't be an unwrap/expect since it doesn't actually panic.