Skip to content

Mark Result::is_ok as #[must_use] #59610

Closed
@alex

Description

@alex
Member

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.

Activity

added
C-enhancementCategory: An issue proposing an enhancement or a PR with one.
A-lintsArea: Lints (warnings about flaws in source code) such as unused_mut.
T-libs-apiRelevant to the library API team, which will review and decide on the PR/issue.
on Apr 1, 2019
shepmaster

shepmaster commented on Apr 1, 2019

@shepmaster
Member

Duplicate of #48926

varkor

varkor commented on Apr 1, 2019

@varkor
Member

@alex: feel free to open a pull request adding #[must_use] to is_ok.

shepmaster

shepmaster commented on Apr 2, 2019

@shepmaster
Member

@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?
  • Should it be every method in Result?
  • What about Option?
  • etc.
varkor

varkor commented on Apr 2, 2019

@varkor
Member

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

shepmaster commented on Apr 2, 2019

@shepmaster
Member

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

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.

added a commit that references this issue on Apr 15, 2019

Rollup merge of rust-lang#59648 - alex:must-use-result, r=alexcrichton

92702c1
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    A-lintsArea: Lints (warnings about flaws in source code) such as unused_mut.C-enhancementCategory: An issue proposing an enhancement or a PR with one.T-libs-apiRelevant to the library API team, which will review and decide on the PR/issue.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

      Development

      No branches or pull requests

        Participants

        @alex@shepmaster@jonas-schievink@varkor

        Issue actions

          Mark Result::is_ok as #[must_use] · Issue #59610 · rust-lang/rust