Standardize DType match arms to follow variant declaration order

[connortsui20]

Reorder DType match arms across the codebase to match the order of the
DType enum declaration, and move Extension after Variant so that
Extension is the last variant in the enum (and in all match statements).

This is a purely cosmetic refactor with no functional changes:

• The protobuf, flatbuffer, and serde wire formats are preserved (only the
  source order of match arms is changed, not the discriminant/tag values).
• The public API surface is unchanged; public-api.lock files are
  alphabetical so they require no update.

Signed-off-by: Claude noreply@anthropic.com

[robert3005]

I don't think this is worth it. While I understand it makes more sense to be consistent you gain nothing without writing a rule that enforces this in perpetuity. I would be happy to merge a pr like this if it came with a clippy rule

[connortsui20]

This doesn't have to be a rule though?

It is not a big deal if they are not in the same order, the issue is that with 11 (soon 12) variants we should remove any amount of overhead when trying to grok the code. It can be confusing when arms are in completely different orders, so why not just clean this up?

[robert3005]

The claim I am making is that you're not removing any complexity, you're just moving it to suit your preferences. Removing complexity imho is automating this change but then there's complexity w.r.t. the calling code doing something special with certain variants

[connortsui20]

I disagree that moving code around is simply to suit someone's preferences, if that were the case then we should just put everything in a single file (since it is just a preference that we break modules into files).

I don't understand why this is a crazy change given it is in an effort to make code more consistent and readable top to bottom (which is often what people new to a codebase will do).

I understand that it is not the ideal (the ideal would be that there is a lint where if a match statement has all possible arms handled it orders them), but to say that because the ideal cannot be automated we should just give up entirely is somewhat confusing to me.

There is a similar issue with some of our trait implementations where the order of methods is not always consistent with the trait definition and there is a rust analyzer action that fixes this, but it cannot be "automated". Are we really going to say that if someone decides to fix that we're not going to accept that change because there might be some drift later?

[robert3005]

This is not a crazy change, this is an unnecessary change. I am not saying any of what you're implying. I am saying that you shouldn't merge pure cleanups without rules and you can merge cleanups with changes to the code you're touching

[connortsui20]

The only reason I split this out was because @joseph-isaacs asked me to split it out of #7890 (which is now #7897)