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

Matching on an enum shouldn't require full scoping inside the match #16681

Closed
mdinger opened this issue Aug 22, 2014 · 6 comments
Closed

Matching on an enum shouldn't require full scoping inside the match #16681

mdinger opened this issue Aug 22, 2014 · 6 comments

Comments

@mdinger
Copy link
Contributor

mdinger commented Aug 22, 2014

// main.rs
extern crate really;

fn main() {
    let my_enum = really::long::A;

    // This match works with full scoping
    match my_enum {
        really::long::A => {},
        really::long::B => {},
        really::long::C => {},
        really::long::D => {},
        really::long::E => {},
        really::long::F => {},
        really::long::G => {},
    }

    // This doesn't because the scope is missing but the scope
    // doesn't add anything because it's matching variants of an
    // already defined enum.  This should work.
    match my_enum {
        A => {},
        B => {},
        C => {},
        D => {},
        E => {},
        F => {},
        G => {},
    }
}
// lib.rs
pub mod long;
// long.rs
pub enum Enumeration {
    A,
    B,
    C,
    D,
    E,
    F,
    G,
}

I was trying to de-glob libsyntax (#11983) but this is a real nuisance there. The enums are much much bigger than this.

I hope this is clear. Let me know if it isn't.

@alexcrichton
Copy link
Member

This is currently a fact of rust's module system and the way that enums are scoped in their enclosing module. You can use each variant of the enum to bring it in scope, otherwise you need to qualify it through some other path.

You do not have to use the full path of an enum, just some path which resolves to the enum variant. For now though this is working as intended, so I'm going to close this.

@mdinger
Copy link
Contributor Author

mdinger commented Aug 22, 2014

Maybe it was unclear but I didn't intend to show this as an error that Rust is making but as room for possible improvement, like a feature. I learned on IRC that the current behavior is intended but I thought my second match seems much better (and reasonable).

Hopefully this would be a possible future improvement, though maybe after 1.0 (I know you guys are busy). You didn't seem to indicate if this type of improvement is outside the realm of possibility in the future though.

@alexcrichton
Copy link
Member

The leading proposal I know of for this is enum mod, but regardless a change such as this would need to go through the RFC process.

@mdinger
Copy link
Contributor Author

mdinger commented Aug 23, 2014

Okay that's fine. Thanks for pointing me in the correct direction. enum mod appears to be here: #10090

@mdinger
Copy link
Contributor Author

mdinger commented Oct 27, 2014

@nick29581 It seems this should be an RFC issue. Could you clone it to RFCS (I think I'm supposed to ask you)? I just want it filed in the correct location.

@rust-highfive
Copy link
Collaborator

This issue has been moved to the RFCs repo: rust-lang/rfcs#421

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