enhancement request - derive sorting

[sagiegurari]

maybe like you are sorting the 'use' lines and values, you could also sort the derive values, for example

#[derive(Serialize, Deserialize, Debug, Clone)]

can be sorted by abc order and keep the code consistent all over.

[nrc]

We can't do this because the order of derives can be semantically important (a derive only sees following derives, so in your example, Debug only sees Clone) and re-ordering could thus break some custom derives.

[sagiegurari]

Ok didnt know

[upsuper]

Although order of derives can be semantically important, I believe majority of custom derives don't care about other derives, and it could almost certainly be surprising if a custom derive is sensitive to the order.

So I think it is probably a good idea for rustfmt to support sorting derives (maybe as an opt-in for now), and discourage custom derive to rely on its position in derive list.

There are projects, e.g. Stylo, try to sort the derives. An example can be seen here. Without rustfmt's help, it needs to be maintained manually, which is error-prone.

[scampi]

I didn't know before now the order is important. If a derive is sensitive to order, then I imagine the confusion from the user in case of an error.
Even if the option is an opt-in, a user may enable it knowingly but forget about it later, and would be caught by it...

[upsuper]

Even if the option is an opt-in, a user may enable it knowingly but forget about it later, and would be caught by it...

As I mentioned, I think it should generally be considered a bad practice to have derive order sensitive.

Doing so would surprise users anyway, given how few people are aware of it, regardless of whether rustfmt would sort it.

[thomaseizinger]

Even if there is a derive that is dependent on the order, it would be good practice by the maintainer to chose the name in a way so that the order is enforced by rustfmt :)

[kangalio]

This issue should be reopened. Many options could already theoretically break custom proc macros (e.g. all options that modify AST: 1, 2, 3, 4, 5, 6, 7...). That is fine because proc macros shouldn't depend on such details and deserve to break if they do. Same applies here.

Plus, this option would be opt-in anyways, so users would know what they're getting into when enabling this option.

It would be nice to have this option for serenity