Generate less code when deriving

[bluss]

Here are some ideas for generating less code when deriving. All of these break down with generic fields, since then we have to fall back to the current general scheme.

PartialEq

For C-like enums, only produce eq and not ne. The default ne calls eq and is always enough. Edit: implemented in #31977.

PartialOrd

For C-like enums only produce partial_cmp and not the four other methods lt, le, gt, ge. This needs an experiment to see if only partial_cmp is good enough. Maybe another of the single methods can be enough, too.

PartialOrd, Ord together

When there are no generic parameters, simply call .cmp() in .partial_cmp().

cc @durka

[durka]

Seem like good ideas in general. Why do you assume that omitting ne is good but omitting gt might not be?

Do we have a derive-heavy crate somewhere that'd be good for compile-time and runtime benchmarks?

[bluss]

ne just uses !eq, but gt uses a slightly more complicated expression based on the return value of partial_cmp.

[ollie27]

Does it make sense to derive an implementation of ne for any types? It's impossible to implement it in a way that's faster than !eq.

[durka]

@ollie27 if we don't call ne() for the inner types, then it's an observable behavior change.

[ollie27]

While it's technically observable we have a rule "!(a == b) if and only if a != b" in PartialEq so any PartialEq implementation for which it is a behaviour change is broken anyway.

[durka]

While I agree this was not a convincing argument over at #31414 so I recommend we keep this PR small :)

[bluss]

Why do we even have two methods then?

@ollie27 I agree with your observation. And isn't it so that any fast path to either proving equality or nonequality (whichever is easier), is applicable in both .eq and .ne?

[ollie27]

Yeah, if there's a fast path for one then the fast path for the other is just negating the output. I don't think there's ever a reason to override ne() and I think it only exists so the operator != has something to map to.

[Mark-Simulacrum]

performance testing for leftover cases seems to indicate this is mostly a wash on real-world code so closing this.