The style guide lives in the rust repo , which has over 5k issues. I'm guessing that raising an issue there is not the right place to discuss changes to the style guide, or is it?
For reference, I raised an issue with rust-analyzer to change the default import granularity to "item" for improved merge-friendliness. It was commented that this should be clarified upstream in the style guide, before rust-analyzer changes its default unilaterally.
opened 09:27AM - 05 Oct 25 UTC
C-feature
There was recently some discussion around rustfmt's handling of import statement… s. The trigger was Linus Torvalds complaining on the LKML about merge conflicts in nested `use` expressions.
Many people in the Rust community (although certainly not all) seem to agree that the default handling of import statements is not ideal. Particularly because it leads to textually difficult to resolve merge conflicts.
One solution that came up in the discussion is to configure rustfmt with `imports_granulartiy = "item"`. Unfortunately, this configuration option is unstable and unlikely to stabilize soon.
But rustfmt's default setting is to preserve the import style as-is. Which means, the problem would practically be solved if the imports were just written in an itemized style to begin with. I and probably most other Rust developers don't write imports themselves, but let rust-analyzer handle it for them. Therefore, the problem would practically be solved if rust-analyzer defaulted to the configuration option `imports.granularity.group = "item"`.
There is a bit of a trade-off between verbosity and ease of handling merge conflicts here. I personally believe the issue of merge conflicts is more important, because people rarely "read" all import statements from top to bottom, they just scroll past. Another argument is this: Merge conflicts are more important in large projects with many contributors. If such a project has to go out of their way to configure the imports granularity, the effort is relatively high. Since rust-analyzer's configuration is editor dependent, there would have to be in-repo configuration / documentation for every editor used by contributors. On the other hand, if somebody is working on a small project without any collaborators (where merge conflicts are not a problem), it's very easy for them to configure a different imports granularity just for themself.
One case study here is [Jujutsu](https://github.com/jj-vcs/jj), a Git-compatible VCS written in Rust. They use imports granularity "item". Many contributors end up installing the nightly toolchain and configuring rust-analyzer to use nightly rustfmt _just for that_. New contributors often run into annoying CI issues because their default rustfmt + rust-analyzer setup generates incorrectly formatted use statements.
Discussion on Reddit:
https://www.reddit.com/r/rust/comments/1nwt8nm/linus_torvalds_vents_over_completely_crazy_rust/
Linus Torvald's email on the LKML:
https://lore.kernel.org/lkml/CAHk-=wgO7S_FZUSBbngG5vtejWOpzDfTTBkVvP3_yjJmFddbzA@mail.gmail.com/T/#me533a148abe97c29e0e7150508c42345b2a64e13
If it is appropriate, I'm also happy to discuss that issue here directly.
I think I changed my mind. The chances of the proposal being accepted are slim. The style guide is explicit about wanting to limit vertical space used by imports.
The discussion on the rust-analyzer issue yielded a decent workaround for big projects that need to optimize for merge-friendliness, instead of vertical space usage.