let_underscore_drop warns even when drop order is not affected

[saethlin]

Lint name: clippy::let_underscore_drop

In this context, the semantics of _ do not alter drop order (which is the reason the lint exists, I think?) but the lint fires anyway:

struct FlushOnDrop<T: std::io::Write>(T);

impl<T: std::io::Write> Drop for FlushOnDrop<T> {
    fn drop(&mut self) {
        let _ = self.0.flush();
    }
}

Meta

• cargo clippy -V: clippy 0.1.52 (476acbf 2021-03-03)
• rustc -Vv:

  rustc 1.52.0-nightly (476acbf1e 2021-03-03)
  binary: rustc
  commit-hash: 476acbf1e9965b5e95c90f0d7d658709812b7003
  commit-date: 2021-03-03
  host: x86_64-unknown-linux-gnu
  release: 1.52.0-nightly
  LLVM version: 11.0.1
  

[camsteffen]

I would prefer to keep the rules of let_underscore_drop simple. You could change to let _result = or use drop.

[repi]

Want to use this lint but this is the main reason we do not use it, there is no change in semantics or flow here so requires a lot of unnecessary changes for it to not warn about these cases.

[camsteffen]

Related: #6842 (maybe we can introduce a workaround that a type annotation let _: Result<_, _> = .. will suppress the lint)

The idea of the lint is that using let _ = .. to drop a value is not explicit enough and drop(..) should be used instead. Even if that does not change semantics, it still affects readability of the code since it is not as plainly obvious that a Drop occurs. If you think that let _ = is readable enough, then I don't think this lint is for you. And that is a perfectly acceptable preference to have, which is why the lint is pedantic.