Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

corrode.dev

Post reply on HN
Print view View original

51–60 of 63 posts

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

#51

Post by mplanchard »

indiv0 wrote: post #50
mplanchard wrote: post #41

Earlier quoted context omitted.

This is nice, but fairly miserable to deal with in in-module unit tests, IMO. We get around it by using conditional compilation and putting the lints in our entrypoints (`main.rs` or `lib.rs`), which is done automatically for any new entrypoint in the codebase via a Make target and some awk magic. As an example, the following forbids print and dbg statements in release builds (all output should go through logging), a…

We just set all the lints to `warn` by default then `RUSTFLAGS="--deny warnings"` when building for release (or in CI).

Yeah that is nice too, and that should also skip all the test code. I think all the clippy warnings on tests for unwrapping and such when working locally would bug me though. And at least the eglot LSP client tends to get bogged down when there are more than a thousand or so clippy warnings/errors, I have found.

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

#52

Post by ziml77 »

ChadNauseam wrote: post #2

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…

I only just learned of that let-else syntax here. I haven't kept a close eye on all the changes to the language over the years, but this is exactly what I've wanted if-let to allow.

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

#53

Post by mre »

Ar-Curunir wrote: post #4

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 =).

Author here; thanks! I had the same impression, which is why I started writing these short-form articles about idiomatic Rust. The blog post overview is here: https://corrode.dev/blog/

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

#54

Post by mre »

sophacles wrote: post #7

> My main gripe with this error message is that it doesn’t explain why the ? operator doesn’t work with Option in that case… just that it doesn’t. The error in question: > the `?` operator can only be used on `Result`s, not `Option`s, in a function that returns `Result` It literally tells you why it doesn't work, wtf do you want?

Fair point. Your wording was a bit strong, but I assume you meant well. I will update the article.

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

#56

Post by spott »

ChadNauseam wrote: post #2

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…

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

Not for Python! There is way more “intro” to Python stuff out there than anything else…

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

#57

Post by quadhome »

evrimoztamur wrote: post #6

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…

All but one of these come from the restriction[1][2] lint group.

I try to remember to look at new restriction lints with every Rust release. For example, here's what new with 1.86.0[3]; the `return_and_then` lint looks pretty nice.

n.b. no one should enable all restrictions lints— some are mutually exclusive, some are appropriate for specialised circumstances like `#[no_std]`. But I find them helpful to keep a project away from the wild parts of Rust.

P.S. `unhandled_errors` doesn't exist[4].

[1]: https://rust-lang.github.io/rust-clippy/stable/?groups=restr... [2]: https://doc.rust-lang.org/stable/clippy/lints.html#restricti... [3]: https://rust-lang.github.io/rust-clippy/stable/?groups=restr... [4]: https://rust-lang.github.io/rust-clippy/stable/index.html#/u...

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

#58

Post by robertlagrant »

38 wrote: post #47
robertlagrant wrote: post #10

Earlier quoted context omitted.

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

Python doesn't have option, so this is not the same thing at all

What if get_user() returns something of type Optional[User]? Does that get it close enough?

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

#60

Post by the__alchemist »

acjohnson55 wrote: post #14
the__alchemist wrote: post #11

Something I use for situations where nesting is getting out of hand. Probably not idiomatic but, I find it practical in these cases. if param.is_none() { // Handle, and continue, return an error etc } let value = param.as_ref().unwrap(); // or as_mut // Use `value` as normal.

Any advantages of this over let-else?

Update: No, I don't think so. Just tried Let Else... I like it more than the ex I posted.

That said, much like it took me a while to Grok if let syntax... this will be a struggle. See the other example in this thread where the one suggesting it reversed the syntax. That will take a bit to get right...

Post reply on HN