Skip to content

Guide: Patterns: use non-x variables in match blocks #18339

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

Merged
merged 1 commit into from
Oct 30, 2014

Conversation

chastell
Copy link
Contributor

I think it helps to show that the variables introduced in match blocks are indeed independent from the matched variable x (especially when x is still reachable inside those blocks and might be useful), so this renames them accordingly. Maybe some linter (or language-level warning?) will eventually warn about shadowing x in such cases. ;)

I’m not super happy about the matching-on-range example, as it’s too contrived (e and x are exactly the same here), but I couldn’t come up with something both simple and non-redundant.

@rust-highfive
Copy link
Contributor

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @nikomatsakis (or someone else) soon.

@steveklabnik
Copy link
Member

Hmm, I'm torn about this. Shadowing is something that we tend to do a lot.

@chastell
Copy link
Contributor Author

Oooh, interesting! Isn’t access to the matched variable in the match block useful sometimes?

(Warning: highly contrived and probably super-unidomatic example ahead; I learned about fmt only now to post this example…)

use std::fmt;

enum OptionalInt {
    Value(int),
    Missing,
}

impl fmt::Show for OptionalInt {
    fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result {
        match *self {
            Value(i) => write!(f, "Value({})", i),
            Missing  => write!(f, "Missing"),
        }
    }
}

fn main() {
    let x = Value(6i);

    match x {
        Value(i) if i > 5 => println!("Got an int bigger than five from {}!", x),
        Value(..) => println!("Got an int from {}!", x),
        Missing   => println!("No such luck: {}.", x),
    }
}

@huonw
Copy link
Member

huonw commented Oct 28, 2014

It seems to me that we should aim to be as clear as possible by default (I.e. no shadowing), and possibly mention shadowing explicitly. FWIW, I don't think shadowing between the match head and subbindings is that common, normally plain locals.

@steveklabnik
Copy link
Member

@huonw fair enough! I'm fine with giving this an r+ if you are

@nikomatsakis
Copy link
Contributor

I agree with @huonw

bors added a commit that referenced this pull request Oct 30, 2014
I think it helps to show that the variables introduced in match blocks are indeed independent from the matched variable `x` (especially when `x` is still reachable inside those blocks and might be useful), so this renames them accordingly. Maybe some linter (or language-level warning?) will eventually warn about shadowing `x` in such cases. ;)

I’m not super happy about the matching-on-range example, as it’s too contrived (`e` and `x` are exactly the same here), but I couldn’t come up with something both simple and non-redundant.
@bors bors closed this Oct 30, 2014
@bors bors merged commit aa1cd6e into rust-lang:master Oct 30, 2014
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

Successfully merging this pull request may close these issues.

6 participants