Skip to content
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

Consider warning by default for foo == bar; statements #38224

Closed
crumblingstatue opened this issue Dec 7, 2016 · 4 comments
Closed

Consider warning by default for foo == bar; statements #38224

crumblingstatue opened this issue Dec 7, 2016 · 4 comments

Comments

@crumblingstatue
Copy link
Contributor

One can make a mistake where they mistype = to ==.

Consider the following code:

fn main() {
    let mut a = 10;
    println!("A is {}", a);
    if 1 == 2 {
        a = 20;
    } else {
        a == 30; // Oops, meant assignment
    }
    println!("A is now {}", a); // Still 10
}

No warning is produced for this code.

I'd argue that this is a common enough mistake to justify warning by default for it.

If the user explicitly wants to do this operation for side effects or whatever, they can do let _ = a == b;, similarly to the explicit version for #[must_use] types.

@mbrubeck
Copy link
Contributor

mbrubeck commented Dec 7, 2016

I think this is a good candidate for an on-by-default builtin lint:

  • It catches a typo that is easy to make and difficult to spot, and that won't be caught by type checking.
  • It can be very narrowly targeted, only matching statements of the form EXPR == EXPR;.
  • False positives are unlikely, because == should rarely if ever have side effects, so it almost never makes sense to discard its result.

@crumblingstatue
Copy link
Contributor Author

crumblingstatue commented Dec 7, 2016

False positives are unlikely, because == should rarely if ever have side effects, so it almost never makes sense to discard its result.

We could also show a note/hint to use the more explicit let _ = a == b version in case the user wants to only evaluate side effects.

@nagisa
Copy link
Member

nagisa commented Dec 7, 2016

I think this is a good candidate for an on-by-default builtin lint

Needs RFC.

@crumblingstatue
Copy link
Contributor Author

Closing in favor of rust-lang/rfcs#1812.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants