Rustfmt: enhancement request - derive sorting

Created on 9 Aug 2017  路  7Comments  路  Source: rust-lang/rustfmt

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

````rust

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

````

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

Most helpful comment

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.

All 7 comments

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.

Ok didnt know

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.

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...

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.

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 :)

This would be a great option, but by default it should be turned off.

For my personal taste of the rustfmt configurations, I would turn this on, and merge_derives off, if I need a derive that is order sensitive, then I leave it on top of the other.

[derive(SensetiveOne)]

[derive(others... ordered!)]

EDIT: link to rfc: https://github.com/rust-dev-tools/fmt-rfcs/issues/154

Was this page helpful?
0 / 5 - 0 ratings