Semver implications of reordering enum variants

[obi1kenobi]

Is reordering enum variants considered semver-major, minor, or patch? It definitely could change the outcomes of use of std::mem::discriminant(), but some technically-might-be-breaking changes are not considered semver-major (e.g. adding a method) so I feel this isn't a clear-cut case.

The API evolution RFC does not address this either.

[Lokathor]

The precise output of std::mem::discriminant is completely non-stable across compiler versions, so there's absolutely no reason to think it's stable across library versions either.

[obi1kenobi]

Thanks for taking a look here and sorry for the late reply — I was traveling and AFK for a while. I'd love your help in sorting this out! std::mem::discriminant is only a small portion of the surface area here, and I probably could have done a better job explaining that in the initial issue.

Here's a specific case without std::mem::discriminant that I'm not sure about.

The Implicit discriminants section of the reference defines the numeric values discriminants produce when cast to an appropriate numeric type: either isize or the explicit primitive representation in the repr, if one is present.

The Casting section on that page has the following example:

enum Enum {
    Foo,
    Bar,
    Baz,
}

assert_eq!(0, Enum::Foo as isize);
assert_eq!(1, Enum::Bar as isize);
assert_eq!(2, Enum::Baz as isize);

Reordering the variants inside the enum would break this example. If the enum is pub, then this is a breaking change for the API. But is it semver-major?

[obi1kenobi]

I believe that #[derive(PartialOrd)] is another way to externally observe enum variant order: reordering variants may cause a change in the observed sort order.