Comment by Twey
8 hours ago
This would have been flagged by Clippy lints `let_underscore_untyped` or `let_underscore_must_use`, which sadly are not enabled by default.
8 hours ago
This would have been flagged by Clippy lints `let_underscore_untyped` or `let_underscore_must_use`, which sadly are not enabled by default.
Or just by not writing let _ =
All recurrent people problems are system problems.
As seen by the fact that forcing the programmer to write let _ = to silence the warning did not fix the bug.
You know what might've solved this though? Using threads instead of async
Ehh, easy fix
I said ‘flagged’, not ‘fixed’ :)
You can always write the wrong code if you want it enough. But hopefully a warning would have prompted someone to think harder about this flow.
But "let _ =" is already an explicit suppression of a must-use warning. Where does this arms race of "no, I really know what I am doing, compiler" versus "no, this really looks like a mistake, programmer" end?
2 replies →
And this is why you should warn on `clippy::allow_attributes_without_reason` in your projects.
You can set the lints to `forbid` instead of `deny`, which means they can't be `allowed` like that.
Yeah, but you must know about them and the possible bug first in order to allow them...
Hence ‘sadly’. IMNSHO both of these (or at least _untyped) should be enabled by default. Untyped `let _` is too big a footgun during refactorings.
At which point you wouldn't have written this bug in the first place; or the warnings would trigger immediately, you'd change _ to an actual variable and then remove the warning pragmas because now you don't assign to _.
1 reply →
Not really. If I'm using a linter, I go and configure the strictest possible ruleset, and only disable rules when justified on a need-by-need basis. It's just a matter of discipline.
[flagged]