Implement Ord for mem::Discriminant

[MoSal]

Sorting a collection by variant can be useful. For example, to implement PartialEq in a simple way.

[mbrubeck]

This was brought up in #24263 (comment) and there were no objections, but it was determined not to be a blocker for stabilization.

[scottmcm]

I'm opposed to this since it means that any reordering of enum variants is now a runtime breaking change. Right now reordering is fine as long as the enum author didn't derive (Partial)Ord; making variant order always observable to anyone takes that out of the type's author's control.

[MoSal]

@scottmcm

That's a good point that I can't but agree with.

OrdDiscriminant with unsafe discriminant() would still be very useful though.

[scottmcm]

I don't think unsafe is needed or solves the problem. A marker trait so that impl<T: ExposeVariantOrder> Ord for Discriminant<T> could work, though, so that the same things are possible, it's just under the control of the author of the type.

(And I kinda want a lint about derive(Ord) without that, but that's just a personal neurosis.)

[Mark-Simulacrum]

It seems like if you would bother implementing the marker trait then you might as well provide a PartialOrd impl or a variant() -> CustomDiscriminant function; either way, this seems rare enough that it's not worth landing in std.

[daxpedda]

In derive-where we wanted to use this to properly implement PartialOrd and Ord, doing this manually is ugly and might even lead to bad codegen:

impl Ord for Test {
    fn cmp(&self, other: &Self) -> Ordering {
        if mem::discriminant(self) == mem::discriminant(other) {
            Ordering::Equal
        } else {
            match self {
                Test::A => Ordering::Less,
                Test::B => match other {
                    Test::A => Ordering::Greater,
                    _ => Ordering::Less,
                },
                Test::C => match other {
                    Test::A | Test::B => Ordering::Greater,
                    _ => Ordering::Less,
                },
                Test::D => Ordering::Greater,
            }
        }
    }
}

Versus:

impl Ord for Test {
    fn cmp(&self, other: &Self) -> Ordering {
        let self_disc = mem::discriminant(self);
        let other_disc = mem::discriminant(other);

        if self_disc == other_disc {
            Ordering::Equal
        } else {
            Ord::cmp(&self_disc, &other_disc)
        }
    }
}

The argument against it because of stability is a bit confusing to me, to quote Rusts standard library mem::discriminant:

Stability

The discriminant of an enum variant may change if the enum definition changes. A discriminant of some variant will not change between compilations with the same compiler.

Maybe this was added later?

In any case, to efficiently implement Ord and PartialOrd for large enums requires this, unless I'm missing some alternative? Is there a way to revive this or should I open a new issue? Is a PR welcome?