If the book is going to show off enum variant comparison with `==`, it also needs to talk about PartialEq

[bstrie]

A cousin to #17967.

The relevant bit of the docs is here: http://doc.rust-lang.org/book/compound-data-types.html#enums

The problem with this is that it's showing off the ability to compare enum variants with ==, which, aside from being something that almost never happens in practice, continually confounds users who expect it to automatically work on enums that they define themselves. That this section of the guide has been a stumbling block for so long (#17675, #18155) should be throwing up red flags by now.

If nothing else, it needs to contain a footnote/link/code comment giving some hint as to PartialEq's existence. If that would be out-of-scope for this chapter, then the section needs to be revised to eliminate the usage of ==.

[G4MR]

Yeah when I was running through the book my flow usually goes along the lines of recreating the example in a similar manner, but not exactly copying the code so when I went to create my example to see the basic usage shown in the example:

fn main()
{
    enum AgeScaling {
        Kid,
        Teen,
        Adult
    }

    let cmp = |&: age: i32| -> AgeScaling {
        if age <= 12 {
            AgeScaling::Kid
        } else if age < 18 && age > 12 {
            AgeScaling::Teen
        } else {
            AgeScaling::Adult
        }
    };  

    let yourscale = cmp(17);
    if yourscale == AgeScaling::Adult {
        println!("You're allowed to watch adult videos");
    } else {
        println!("Go away");
    }
}

I would get binary operator == annot be applied to type AgeScaling, which is confusing because my example is almost exactly similar to the example in the book. This made me think everything I was doing wrong so I googled and found out that I needed to use [derive(PartialEq)](actually it shown deriving, but I remember reading deriving was deprecated about a week or so ago when I was messing around with rust and sdl2 so I changed it to derive) above my enum and everything was sorted.

My issue with this is there will be multiple "beginners" reading this guide, doing exactly what I did and coming across googling and noticing the book doesn't talk about this usage at all. In my opinion the book shouldn't use the build in Ordering enum because it won't have the exact results as someone doing what I did and also talk about the [derive(...)] stuff explaining you haven't seen this before, but we'll explain it more in a future part of the book.

[estsauver]

The pattern that I've seen in docs around this that I really appreciate is when guides go to the effort of showing how we could build standard things (like the ordering enum), and then showing that they already exist in the standard library.

If there's agreement we should make this change, I can put together a PR changing this section of the book.

[mdinger]

I put up PR #21207 to try to address this. Comments may be helpful.

[mdinger]

The enum section has changed since this was filed. If this bug is still valid, can you revise the summary accordingly.

[steveklabnik]

Yes, I think this is fine now.