Re:Rust should not have provided `unwrap`
by throwaway234232 on Friday July 15, 2022 @02:54PM
(#32111571)
Your example doesn't help your argument here, as square should be taking `T` instead of `Option<T>`, a good use case for `Option::map`.
But if you are speaking about ergonomics of handling Options, it is being improved upon with the usage of try operators with Options as well as possibly seeing try expressions in the near future.
I don't think lack of ergonomics is a good justification for usage of unwrap, but that is entirely subjective. However, I do see the misappropriation of `unwrap` as a signal that the ergonomics in Rust are lacking and it's something that needs to be addressed, so again I do sympathize.
For the specific examples you have here you can shorten it a bit and use anyhow's OptionExt::context and avoid the closure. Someday maybe we'll have postfix macros and you'll even be able to format in it.
You can use "unwrap()" on an Option, but you can't use "?". You have to write something like
which is a bit unwieldy. becomes A default message would be useful.Bailing out of the middle of a map expression's closure is complicated. In that situation, "?" causes a return of the expression in the closure, not the whole map. There's a clever way around this.[1] It supposedly gets optimized so that the iteration quits early, and an array of Result types is not generated and then flattened.
You never really need unwrap, but the "right way" can be verbose.
[1] https://stackoverflow.com/questions/26368288/how-do-i-stop-i...