-
Notifications
You must be signed in to change notification settings - Fork 13k
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
Comments
shoud put #[deriving(PartialEq)] befre enum. |
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 |
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 Someone remind me, why do we have |
This would be a pretty elegant answer to this problem. I love shadowing in general, but it causes problems in situations like these. |
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. |
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 |
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. |
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.
|
Now that it's been removed from the prelude, we need to treat things differently. Fixes rust-lang#17967
Now that it's been removed from the prelude, we need to treat things differently. Fixes rust-lang#17967
Now that it's been removed from the prelude, we need to treat things differently. Fixes rust-lang#17967
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`.
There error message is:
The text was updated successfully, but these errors were encountered: