You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 like expect(). Had is_ok been marked #[must_use] this mistake would have been prevented.
@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:
why not also is_err?
What makes those two methods special compared to Result::ok?
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 #[must_use], but it seems clear that if a method is effectless and can be confused with an effectful variant, marking as #[must_use] is definitely what we want to do and waiting on a general guideline now just leaves the behaviour subpar (especially as the tracking issue has not seen much progress recently). Specifically in this situation, we have a concrete instance of a particular method being misused and causing practical problems.
I do think if a pull request was opened, it should include is_err. I agree broader questions should be left to the tracking issue. Maybe the best option would be to open a pull request and r? a libs team member, if there's any controversy.
Activity
shepmaster commentedon Apr 1, 2019
Duplicate of #48926
#[must_use]
functions in the standard library #48926#[must_use]
functions in the standard library #48926varkor commentedon Apr 1, 2019
@alex: feel free to open a pull request adding
#[must_use]
tois_ok
.shepmaster commentedon Apr 2, 2019
@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:
is_err
?Result::ok
?Result
?Option
?varkor commentedon Apr 2, 2019
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
#[must_use]
, but it seems clear that if a method is effectless and can be confused with an effectful variant, marking as#[must_use]
is definitely what we want to do and waiting on a general guideline now just leaves the behaviour subpar (especially as the tracking issue has not seen much progress recently). Specifically in this situation, we have a concrete instance of a particular method being misused and causing practical problems.I do think if a pull request was opened, it should include
is_err
. I agree broader questions should be left to the tracking issue. Maybe the best option would be to open a pull request and r? a libs team member, if there's any controversy.shepmaster commentedon Apr 2, 2019
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.
Rollup merge of rust-lang#59648 - alex:must-use-result, r=alexcrichton