3 ms·
`unwrap` is fine. As the author mentions, it can be converted into `?` without much hassle if the function return type can be changed easily. And `?` looks clea
by dymk 4y ago
`unwrap` is fine. As the author mentions, it can be converted into `?` without much hassle if the function return type can be changed easily. And `?` looks cleaner than `unwrap`, so the incentives are aligned to nudge developers towards that instead.
`unwrap` is plenty explicit, and developers know exactly what it does (and that it might panic) once they've spent a few hours with Rust. It's not the subtle footgun the author is making it out to be.
- oxff 4y agoSometimes you don't want to use `?` though, not every function is made to return a Result / Option.
- dymk 4y agoIn that case, you use `unwrap`, or you manually convert it into your return type, or you provide an `impl Try` [0] for your return type once that feature becomes stable (already possible if you're on nightly) [0] - https://github.com/rust-lang/rust/issues/84277 https://github.com/rust-lang/rust/issues/84277
- mcronce 4y agoIf your function is fallible, your function is fallible - it's up to you to decide whether that means returning Result or panicking. If you want your function to be infallible, while itself calling a fallible function, you have to handle the error cases from your callees - you have `.unwrap_or_default()`, `.unwrap_or_else()`, `.unwrap_or()`, and simple `match` all in your toolbox to do this.
- throwaway234232 4y agoThe footgun here is that `unwrap` may be used inappropriately, and from what I see using github code search it's used inappropriately quite often.
- dymk 4y agoSo is `panic`, or the subtraction operator on unsigned values which may cause underflow.