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

Rust

111 readers
4 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
you are viewing a single comment's thread
view the rest of the comments
[–] lolcatnip@reddthat.com 4 points 2 months ago (2 children)

Looks like the author missed my main complaint about Rust mutexes, which is that the lock method returns a Result. There should be a try_unlock method for when someone actually wants to handle the rather obscure failure case, and the name lock should be used for a method that panics on failure but returns a value that doesn't need to be unwrapped first. I see the current arrangement as being about as sensible as having array subscripting return a Result to handle the case of a failed bounds check.

[–] BB_C@programming.dev 8 points 2 months ago* (last edited 2 months ago)

If lock-ergonomics^ⓒ^ is as relevant to you as indexing, you're doing it wrong.

I would rather take indexing returning Results than the other way around.

One can always wrap any code in {||{ //.. }}() and use question marks liberally anyway (I call them stable try blocks 😉).

[–] SorteKanin@feddit.dk 3 points 2 months ago

Just use the Mutex from the parking_lot crate.