A Rust match made in hell

Re:A Rust match made in hell by estebank on Sunday May 01, 2022 @11:53PM (#31231281)

On the upper righ side, click on tools and select clippy https://play.rust-lang.org/?version=stable&mode=debug&editio... It will produce the following output:

  error: non-binding let on a synchronization lock
   --> src/main.rs:5:5
    |
  5 |     let _ = m.lock();
    |     ^^^^^^^^^^^^^^^^^
    |
    = note: `#[deny(clippy::let_underscore_lock)]` on by default
    = help: consider using an underscore-prefixed named binding or dropping explicitly with `std::mem::drop`
    = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#let_underscore_lock

Clippy is a third party tool, but highly recommended because of things like this. I would like to see this lint uplifted into rustc.

[ Parent | on HN ]

Re:A Rust match made in hell by tialaramex on Monday May 02, 2022 @02:51PM (#31239228)

Firstly, sincerely thanks for telling me how to add Clippy, that would have been a good idea in this context and now I'll remember it's there.

Secondly, yes, I think should be uplifted. I'd even argue for default deny because I can't think of a reason you would want this behaviour and yet not find this more explicit phrasing more maintainable:

  let guard = m.lock();
  Mutex::unlock(guard); // We don't hold the guard, just touch and go

[I'm assuming anybody who actually wants this would prefer Mutex::unlock() over drop() because it says what's going on, and if they care that they can't write this in stable their effort would be appreciated pushing Mutex::unlock stabilisation rather than blocking a default-deny]

[ Parent | on HN ]

Re:A Rust match made in hell by stormbrew on Monday May 02, 2022 @08:35PM (#31242904)

tbh I would use (and I think have used) drop() for this just because I know drop exists and what it does but Mutex::unlock is something I'd only ever know about if I went and scanned the whole Mutex page on rustdoc.

I like the idea of these sorts of "drop-with-semantics" functions, but in practice until/unless they add a way to `impl !Drop` (or maybe `#[deprecated]` on a trait impl so you can add a deprecation note on your `impl Drop`) on a type, I'm not sure they're worth it.

[ Parent | on HN ]