You can replace this with a match statement to avoid the unwrap.

It does introduce another layer of nesting in the code, which can be undesirable from a readability perspective at times

Not necessarily, you can extract the inner type by using the match as an expression, e.g.:

``` let val = match res { Err(e) => { ... return ...; } Ok(v) => v, }; // Use val without unwrapping here. ```

That said, even though I'd avoid unwrap in this particular case in my code, I generally disagree with the author.

Taking out unwrap and leaving in expect would simply lead to a bunch of code that goes `let val = result.expect("!");`, which is equivalently bad when held up against the criticisms the author makes of unwrap.

Unwrap isn't really harmful so much as a symptom and an escape valve around the fact that our type systems really aren't powerful enough to derive all the invariants the programmer can about their code.

Rust is getting let-else to solve that problem: https://rust-lang.github.io/rfcs/3137-let-else.html

Ahh, looks nice, here's hoping it gets stabilized

Fwiw there’s a small crate called guard which has provided this feature for several years.

I heartily endorse it.

Wow, this would definitely make it much cleaner!

Of course, but I think this approach signals intent a bit more clearly: we want to get error handling out of the way and then just proceed with the happy path. It’s also a tad less verbose.

I'd use a 'if let' for something so short.

This is a good use case for let-else, however I won't agree with you here on usage of unwrap for the sake of brevity. I will opt for `?` or match instead.