-
Notifications
You must be signed in to change notification settings - Fork 12.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Mark Result::is_ok as #[must_use] #59610
Comments
Duplicate of #48926 |
@alex: feel free to open a pull request adding |
@varkor doesn't that rather ignore the intent of the linked issue where the libs team is attempting to decide by what rationale functions should and should not have the annotation? Arbitrarily picking functions seems like a poor avenue to go down. For example:
|
In the past, pull requests for individual methods have been accepted (e.g. #50177, #58145, #49533). The purpose of the tracking issue seems to me to decide on an overarching set of rules for I do think if a pull request was opened, it should include |
It's probably worth attempting to say something to that effect on the tracking issue. I do agree that it's a shame that it's moving so slow; you can even see some comments from me with issues I've seen in the wild. |
Add must_use annotations to Result::is_ok and is_err Discussed in rust-lang#59610
I just ran into a project where
Result::is_ok
was accidentally being called without using the result -- I believe it had been confused with an assertion method likeexpect()
. Hadis_ok
been marked#[must_use]
this mistake would have been prevented.The text was updated successfully, but these errors were encountered: