One of Rust’s core benefits seems to be its error-handling strategy; Joe Duffy, for instance, mentions several times throughout his post on error-handling in Midori that Rust appears to support exactly the sort of error model he’s promoting. And one of the best things about Rust’s error-handling is that it makes error handling difficult to avoid.
But my experience in unsafe languages is that developers often treat warnings as “warts”–ugly messages that simply aren’t important enough to address consistently. Without
-Werror, C and C++ projects can quickly become full of warnings that developers rarely even bother to read.
So in the case of the
#[must_use] attribute (and especially its application to the
Result type), the author of a function is attempting to demand that a particular scenario be handled or at least explicitly ignored, but a programmer who calls that function can in fact get away without even noticing that they’ve done anything wrong (in the case where their code already produces lots of warnings that are ignored).
I realize that ignoring warnings–and especially ignoring lots of warnings–probably isn’t considered “good practice” in Rust. But it’s not “good practice” in C or C++, either, which just shows how far “good practice” gets you.
Is there a reason for making this attribute trigger a warning rather than an error? Was there internal discussion about how the attribute should behave?