rustfmt
rustfmt copied to clipboard
rust-lang
Feature request: alphabetic sorting of struct/enum fields
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.
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.
@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
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.
I hope this will be added someday. It will save the minutes spent sorting them manually.
:+1: 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)].
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.
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
+1, I need this as I'm working with massive structs to accept an API's response!
The complexity is in, ‘Whenever the order of a struct or enum would be completely irrelevant’ ...
@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.
You presuppose users would want to invest time in specifying such an attribute. And what about repr(C) structs?
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?
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.
@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.
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