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

The enum type in Guide is not working #17967

Closed
chenyukang opened this issue Oct 12, 2014 · 8 comments
Closed

The enum type in Guide is not working #17967

chenyukang opened this issue Oct 12, 2014 · 8 comments

Comments

@chenyukang
Copy link
Member

enum Ordering {
    Less,
    Equal,
    Greater,
}

fn cmp(a: int, b: int) -> Ordering {
    if a < b { Less }
    else if a > b { Greater }
    else { Equal }
}

fn main() {
    let x = 5i;
    let y = 10i;

    let ordering = cmp(x, y);

    if ordering == Less {
        println!("less");
    } else if ordering == Greater {
        println!("greater");
    } else if ordering == Equal {
        println!("equal");
    }
}

There error message is:

<anon>:21:8: 21:24 error: binary operation `==` cannot be applied to type `Ordering`
<anon>:21     if ordering == Less {
                 ^~~~~~~~~~~~~~~~
<anon>:23:15: 23:34 error: binary operation `==` cannot be applied to type `Ordering`
<anon>:23     } else if ordering == Greater {
                        ^~~~~~~~~~~~~~~~~~~
<anon>:25:15: 25:32 error: binary operation `==` cannot be applied to type `Ordering`
<anon>:25     } else if ordering == Equal {
                        ^~~~~~~~~~~~~~~~~
error: aborting due to 3 previous errors
playpen: application terminated with error code 101
@chenyukang
Copy link
Member Author

shoud put #[deriving(PartialEq)] befre enum.

@garrickp
Copy link

garrickp commented Nov 3, 2014

The documentation at http://doc.rust-lang.org/guide.html#compound-data-types for the nightly build is still missing the note from chenyukang (which does work for me).

Docs are: Rust 0.13.0-nightly b87619e
Rust version is: rustc 0.13.0-nightly (b87619e 2014-11-02 23:27:10 +0000)

@bstrie bstrie reopened this Nov 3, 2014
@bstrie bstrie changed the title The enum type in Guide is now working The enum type in Guide is not working Nov 3, 2014
@bstrie
Copy link
Contributor

bstrie commented Nov 4, 2014

Reopening because this is still broken, and for an especially pernicious reason. The guide automatically tests code examples by running each code snippet in isolation. The following snippet, as tested by the docs, is completely legal by itself:

fn cmp(a: int, b: int) -> Ordering {
    if a < b { Less }
    else if a > b { Greater }
    else { Equal }
}

fn main() {
    let x = 5i;
    let y = 10i;

    let ordering = cmp(x, y);

    if ordering == Less {
        println!("less");
    } else if ordering == Greater {
        println!("greater");
    } else if ordering == Equal {
        println!("equal");
    }
}

...however, if you do the sensible thing and concat the two separate code examples together, as a learner would expect, it suddenly fails to compile:

enum Ordering {
    Less,
    Equal,
    Greater,
}

fn cmp(a: int, b: int) -> Ordering {
    if a < b { Less }
    else if a > b { Greater }
    else { Equal }
}

fn main() {
    let x = 5i;
    let y = 10i;

    let ordering = cmp(x, y);

    if ordering == Less {  // error: binary operation `==` cannot be applied to type `Ordering`
        println!("less");
    } else if ordering == Greater {
        println!("greater");
    } else if ordering == Equal {
        println!("equal");
    }
}

This is because the Ordering enum here is really just a copy of the Ordering enum that is defined in the standard library and imported automatically by the prelude. So when you try the first code snippet, the one without the enum definition, it works by looking at the implicitly-imported variants. But when you define Ordering yourself, it shadows the existing variants, and because you don't have PartialEq derived it will fail inexplicably.

Someone remind me, why do we have Ordering in the prelude at all?

cc @steveklabnik

@steveklabnik
Copy link
Member

Someone remind me, why do we have Ordering in the prelude at all?

This would be a pretty elegant answer to this problem. I love shadowing in general, but it causes problems in situations like these.

@evangoer
Copy link

Ran into this as well for the reason @bstrie outlined (as have some other people, based on previously closed issues).

What about showing the reader how to create & use their own enum? That's how the previous sections on tuples & structs worked.

@ftxqxd
Copy link
Contributor

ftxqxd commented Nov 22, 2014

The Guide doesn’t explicitly say to try running that portion of code (although it is very easy to make that mistake): it says that Ordering is ‘provided by the Rust standard library’. I think that this could be made clearer by simply expanding on and emphasising the fact that defining it yourself will not necessarily work (e.g., ‘This is an enum that is provided by the Rust standard library, with a few extra bits added to let things like == work’).

@ariddell
Copy link

When I read it, I got the sense that the code should run. I think mentioning that the code will not run as written (in contrast to many of the other snippets) would be a good idea.

@anuj-sahai
Copy link

I got stuck here for a while too. I missed the part about it being in Rust standard library and was quite confused about why OptionalInt enum requires the namespace prefix later in the doc. but Ordering didn't and assumed it might be implicit and that namespaces are optional.

Only after I tried the Ordering example and got the following error did I realize that namspace is a must. The example in the original post above does work if enum values are prefixed with namespace.

ordering.rs:8:16: 8:20 error: mismatched types: expected `Ordering`, found `core::cmp::Ordering` (expected enum Ordering, found enum core::cmp::Ordering)
ordering.rs:8     if a < b { Less }
                             ^~~~

steveklabnik added a commit to steveklabnik/rust that referenced this issue Dec 23, 2014
Now that it's been removed from the prelude, we need to treat things differently.

Fixes rust-lang#17967
alexcrichton pushed a commit to alexcrichton/rust that referenced this issue Dec 23, 2014
Now that it's been removed from the prelude, we need to treat things differently.

Fixes rust-lang#17967
alexcrichton pushed a commit to alexcrichton/rust that referenced this issue Jan 2, 2015
Now that it's been removed from the prelude, we need to treat things differently.

Fixes rust-lang#17967
lnicola pushed a commit to lnicola/rust that referenced this issue Sep 25, 2024
internal: Lay basic ground work for standalone mbe tests

Most of our mbe hir-def tests don't actually do anything name res relevant, we can (and should) move those down the stack into `mbe/hir-expand`.
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

9 participants