Don't unwrap options: There are better ways (2024)

let-else is awesome. definitely my favorite rust syntax. The compiler checks that the else branch will “diverge” (return, panic, break, or continue), so it’s impossible to mess it up.

the article says “It’s part of the standard library,” which gets the point across that it doesn’t require any external dependencies but it may be slightly misleading to those who interpret it literally - let-else a language feature, not part of the standard library, the relevant difference being that it still works in contexts that don’t have access to the standard library.

I tend to use Option::ok_or more often because it works well in long call chains. let-else is a statement, so you can’t easily insert it in the middle of my_value().do_stuff().my_field.etc(). However, Option::ok_or has the annoying issue of being slightly less efficient than let-else if you do a function call in the “or” (e.g. if you call format! to format the error message). I believe there’s a clippy lint for this, although I could be mixing it up with the lint for Option::expect (which iirc tells you to do unwrap_or_else in some cases)

I appreciate the author for writing a post explaining the “basics” of rust. I’ll include it in any training materials I give to new rust developers where I work. Too often, there’s a gap in introductory material because the vast majority of users of a programming language are not at an introductory level. e.g. in haskell, there might literally be more explanations of GADTs on the internet than there are of typeclasses

Really useful article to learn about idiomatic Rust :)

In general I think there is a lack of intermediate Rust material that teaches you common design patterns, idiomatic Rust, and so on.

Even I (someone who's written hundreds of thousands of fairly complex Rust code) learnt about the let-else style solution from this article =).

Talking about unwrapping: I’ve been using a rather aggressive list of clippy lints to prevent myself from getting panics, which are particularly deadly in real-time applications (like video games). unwrap/expect_used already got me 90% of the way out, but looking at the number of as conversions in my codebase, I think I have around 300+ numerical conversions (which can and do fail!)

    [lints.clippy]
    all = "deny"
    unwrap_used = "deny"
    expect_used = "deny"
    panic = "deny"
    indexing_slicing = "deny"
    unhandled_errors = "deny"
    unreachable = "deny"
    undocumented_unsafe_blocks = "deny"
    unwrap_in_result = "deny"
    ok_expect = "deny"

> I believe there’s a clippy lint for this, although I could be mixing it up with the lint for Option::expect (which iirc tells you to do unwrap_or_else in some cases)

It's one lint rule which covers bunch of these _or_else functions: https://rust-lang.github.io/rust-clippy/master/#or_fun_call

And the same in Python:

  if user := get_user() is not None:
    # use user
  else:
    # return error

Although given the happy path code can mean you don't see the error condition for ages, I much prefer this:

  if (user := get_user()) is None:
    # return error

  # use user