Guide: Derive Eq to avoid compile error.

[treeman]

If we copy in Ordering and use it with the following example we'll get a compile error as == has not been defined.

I chose to introduce deriving(Eq, PartialEq) but refer to the later discussion (which I assume is going to come). I'm not sure about the formulation however.

It could have been fine to use match, but it hasn't been presented yet. In the next example though we are using match in the example code, so we could do it here as well. But I'm more inclined to remove the use of match there as well as it might be a bit confusing?

cc @steveklabnik

[steveklabnik]

This is not acceptable, as we haven't covered any of this material yet. And you shouldn't be copying in Ordering.

[steveklabnik]

Sorry, was reading on my phone and didn't notice you added an explanation!

I think the better way to fix this is to just tell people that they don't need to define this, if you feel like this is something people are going to do.

[treeman]

Yes we could simply add a comment, and it would be kind of okay.

We should aim to have the code as copyable as possible however. And I do believe some people will type it all in (I usually do) and it's quite scary to encounter errors when doing this. Also some may try variations of the code, "oh we have an enum Ordering, but I want an enum Color" and then get lost when == errors. But maybe that's also fine if you haven't gone through the guide to the end.

My solution might not be good though. Introducing #[deriving(Eq, PartialEq)] might be too messy for a hasty introduction like this.

Could we consider moving the discussion of match before defining Ordering? This defeats some of the flow between the sections though...

Hmm, if you are still unsure we could just leave it with a comment?

[alexcrichton]

r? @steveklabnik

[steveklabnik]

I don't like this 'solution' and I'm unsure of how much of a problem it really is, or if the root cause can be handled somehow else.

[treeman]

Fixed with #16635.