this post was submitted on 16 Sep 2024
53 points (100.0% liked)

Rust

5771 readers
49 users here now

Welcome to the Rust community! This is a place to discuss about the Rust programming language.

Wormhole

!performance@programming.dev

Credits

  • The icon is a modified version of the official rust logo (changing the colors to a gradient and black background)

founded 1 year ago
MODERATORS
snowe@programming.dev
Ategon@programming.dev
EdTheLegendary@programming.dev
kahnclusions@programming.dev
torcherist@programming.dev
53
[BLOG] Why Rust mutexes look like they do - Cliffle (cliffle.com)
submitted 3 days ago by snaggen@programming.dev to c/rust@programming.dev
19 comments fedilink hide all child comments
you are viewing a single comment's thread
view the rest of the comments
[–] BB_C@programming.dev 2 points 2 days ago* (last edited 2 days ago) (1 children)

a better solution would be to add a method called something like ulock that does a combined lock and unwrap.

That's exactly what's done above using an extension trait! You can mutex_val.ulock() with it!

Now that I think about it, I don’t like how unwrap can signal either “I know this can’t fail”, “the possible error states are too rare to care about” or “I can’t be bothered with real error handing right now”.

That's why you're told (clippy does that i think) to use expect instead, so you can signal "whatever string" you want to signal precisely.

[–] sugar_in_your_tea@sh.itjust.works 1 points 2 days ago

Exactly! My code has a handful of "expect()" calls in it, and each one self-documents why it's okay. It's like a comment, but it appears in logs if it ever triggers.