51–60 of 97 posts
So “fearless concurrency” still only happens when one just decides to not be afraid… :)
This does not appear to be a concurrency bug though?
So much for Rust forcing you to handle errors.
You could say the exact same thing about safety belts and airbags in cars after someone has died in a crash. Why even bother with measures that prevent many problems if they won't prevent all of them, right?
It's the same argument anti-vaxers love to make. "Well you can still get covid after getting the shot", which is something I read and heard quite a lot. That doesn't make the thing useless.
Humans are really dumb.
So much for Rust forcing you to handle errors.
Rust never promised it'll let programmers turn off their brain, that's what LLMs are for.
Earlier quoted context omitted.
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?
IMHO the goal is usually for the compiler not to make these decisions but to provide the tools for the APIs people build to make them. That's kind of passing the buck, though.
I guess in this case the core problem is that the API for these I/O calls has no representation in the type system for what's happening to the buffer. Proxying it as ‘the programmer must think about this code path’ is a reasonable best-effort but, evidently, sometimes inadequate.
Would using Rust have prevented this?
Earlier quoted context omitted.
let _ = …? This is the Rust idiom for “I am intentionally ignoring this return value”. The linter would have caught self.poll_read()?; and in fact one of the options the linter itself suggests in this case is exactly this “let underscore equals” idiom. (Arguably, this code exists because of the linter, not due to its absence!) In any case, the return value is being “handled” - the question mark examines the result an…
>This is the Rust idiom for “I am intentionally ignoring this return value”. That doesn't make the code any less awful, it just makes idiomatic Rust sound awful. Discarding a return value without even a comment to explain why shouldn't be allowed in any critical project, and the linter should be perfectly capable of ensuring that a comment accompanies the discard and complaining loudly when it doesn't.
Force people to handle errors and you end up with the exception fiasco in eg Java where everything ends up being a runtime exception to avoid it
So much for Rust forcing you to handle errors.
From a human perspective we can consider that not handling the error.
But the language has no mechanism for "knowing" that discarding the error is wrong. Discarding errors is a fully valid mechanism that we must be able to do in a program because it is sometimes correct. There really isn't even a sensible way to define a way to "force" a user to "handle" errors. The language can only be designed to make it hard to forget to "handle" them somehow in the way the language sees, but it is always possible for the user to incorrectly handle them, of which discarding them when they shouldn't have is only one particularly cognitively-available option but is hardly the full scope of possibilities. Probably isn't even the most common mistake to make, I would imagine there are far more errors that are not handled "correctly" than ones that are spuriously discarded.
Note I keep saying "language" rather than Rust. All a language can do is surface the issue, and Rust does that. It can't force good code. No language can.
This would have been flagged by Clippy lints `let_underscore_untyped` or `let_underscore_must_use`, which sadly are not enabled by default.