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

Raise an error / warning on single path match #12332

Closed
flaper87 opened this issue Feb 16, 2014 · 5 comments
Closed

Raise an error / warning on single path match #12332

flaper87 opened this issue Feb 16, 2014 · 5 comments
Labels
A-lint Area: Lints (warnings about flaws in source code) such as unused_mut.

Comments

@flaper87
Copy link
Contributor

It is possible to write single path matches, which - although they are correct - are useless (unless I'm missing something). We could catch this cases and raise an error or a warning. I'm personally leaning towards an error, I would prefer keeping the code clean from cases like this.

fn main() {
    match Some(1) {
        _ => {println!("Nothing else could happen")}
    }
}
@alexcrichton
Copy link
Member

These are not quite useless with the new lifetime changes, these two statements have different semantic meaning:

// this is a compile error
let slot = foo.borrow().get();

// this is valid code
match foo.borrow().get() {
    slot => { /* ... */ }
}

@huonw
Copy link
Member

huonw commented Feb 16, 2014

A lint on warn by default (like the other stylistic lints) would be fine for this, no need at all to make it a hard error.

(FWIW, using match is nicer in macros too: can handle structs, enums and tuples uniformly. E.g. deriving does it.)

@huonw huonw added the A-lint label Feb 16, 2014
@Aatch
Copy link
Contributor

Aatch commented Feb 16, 2014

As a more general statement, I think that trying to prevent "pointless" code is a non-starter since there is an enormous amount of such code that can be written. There will always be degenerate cases and I don't think we even need a lint. This is unlikely to represent some bug or lead to bugs.

Bad style is not necessarily indicative of bad code. If you want to keep your code clean from silly constructs, then don't write them!

@flaper87
Copy link
Contributor Author

oh mmh, I meant to target this bug just when using _ cases and I agree a lint would be enough.

It looks like this bug is a dup of #3482

@flaper87
Copy link
Contributor Author

@Aatch I don't fully agree and the fact that good and bad style exists is the reason we have lints and style checkers. The whole point is help people to avoid things like this and to avoid writing awful code too.

I agree bad style is not indicative of bad code. However, in cases like this it's certainly a waste.

flip1995 pushed a commit to flip1995/rust that referenced this issue Feb 26, 2024
Coming back to reviewer rotation

After this current CPP period, in which I set myself as on-vacation to focus on performance, I'm now available again. I'd love if my vacation status wasn't present in version control

changelog:none
r? ghost
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-lint Area: Lints (warnings about flaws in source code) such as unused_mut.
Projects
None yet
Development

No branches or pull requests

4 participants