Hacker News Reader

Comment by dymk | Hacker News Reader

`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.

View on HN

Sometimes you don't want to use `?` though, not every function is made to return a Result / Option.

In 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

If 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.

The footgun here is that `unwrap` may be used inappropriately, and from what I see using github code search it's used inappropriately quite often.

So is `panic`, or the subtraction operator on unsigned values which may cause underflow.

Reply on news.ycombinator.com