Feature request: alphabetic sorting of struct/enum fields

[PvdBerg1998]

Whenever the order of a struct or enum would be completely irrelevant, I like to keep them in alphabetic order. However, this gets slightly annoying to maintain when adding new fields. Therefore I propose an optional automatic sorting attribute, think #[rustfmt::sort].

My first idea was to create a clippy lint for this, but having this done automatically would be the best.

[mwillsey]

On a related note, sorting the arms of a match based on the order in the enum declaration (alphabetical or not), would be quite handy.

[scampi]

@mwillsey you mean to reflect the enum's order on the match ? I don't think that is possible since we have only information coming from the AST

[jeremyBanks]

In addition to being able to sort fields, it would also be nice to be able to sort top-level items (Structs, Traits, etc.) in a file.

[bsodmike]

This would be nice!!

[jendrikw]

I would also like to see this for methods of a trait.

[realsama]

I hope this will be added someday. It will save the minutes spent sorting them manually.

[finnbear]

👍 for opt-in to apply this to all structs, enums, unions, and simple match statements on enums, except repr(C) and friends, enum Enum { Variant = # }, or #[rustfmt(skip)].

[WinkelCode]

Another +1 here, I already naturally try to sort stuff alphabetically, so this would be a time saver and ensure consistency. I also +1 having it optionally available for top-level items as @jeremyBanks suggested.

[laralove143]

fwiw jetbrains ides have a sort lines command (select fields, maybe with opt+up arrow idk for windows, double press shift, type sort lines, hit enter or assign a keybind to sort lines) not ideal but better than manual sorting

[TYTheBeast]

+1, I need this as I'm working with massive structs to accept an API's response!

[bsodmike]

I've asked for this 3-years ago. Oh my... 🤦‍♂️🤦‍♂️🤦‍♂️

[sanmai-NL]

The complexity is in, ‘Whenever the order of a struct or enum would be completely irrelevant’ ...

[WaffleLapkin]

@sanmai-NL I don't think this is a real concern, as the OP suggests, this can be done via an opt-in attribute (#[rustfmt::sort]), in which case a user decides if the order matters or not.

[sanmai-NL]

You presuppose users would want to invest time in specifying such an attribute. And what about repr(C) structs?

[bsodmike]

You presuppose users would want to invest time in specifying such an attribute. And what about repr(C) structs?

Is it possible to have the opt-in attribute (#[rustfmt::sort]) for normal record structs only?

[WaffleLapkin]

You presuppose users would want to invest time in specifying such an attribute.

Yes. I know I would use it in a few places. It would be too annoying as an opt-out (rustfmt shouldn't change semantics by default), but it seems just right as an opt-in.

And what about repr(C) structs?

What about them? If you added the #[rustfmt::sort] attribute to a repr(C) ADT, then you are responsible to making sure that the sorted order of fields/variants doesn't break any assumptions.

[sanmai-NL]

@WaffleLapkin not sure what design you intended, but fields should be sorted by default, and this will generally break repr(C) items. Opting out of it shouldn't require an extra attribute.

[laralove143]

why not implement this as an opt-in rule and also a tag (since rustfmt doesnt support rules being enabled per scope like in clippy yet)? that way people can opt-in to the rule and opt-out for scopes they dont want with #[rustfmt::skip], or opt-in only for scopes they want with #[rustfmt::sorted]

for some libraries, such as api wrappers, not having an option to enable the feature globally would require us to add #[rustfmt::sorted] to nearly every struct