Clarify recommended ordering of groups, even without rustfmt support?

[daboross]

There's an original issue, #24, which discussed imports and ordering of imports.

It was closed with #129, but that pull request seems to only address the part of the issue which rustfmt can currently format (ordering within import groups).

I'm particularly partial to the ordering stated in #24 (comment). Specifically, imports should be split into at least three groups, consisting of:

• imports from 'std'
• imports from external crates
• imports from within the same crate

There don't seem to be any major objections to this in #24 - the only problem is that rustfmt doesn't (or didn't at the time) have enough information to enforce this.

If a PR were made, could fmt-rfcs take stance on this issue and recommend these three groups?

If not, does anyone know a more appropriate place where this convention could be established?

[JeanMertz]

I was looking for the same functionality from rustfmt. I don't believe this was ever implemented, was it? Given the lack of comments, I guess this slipped through, and won't be considered anymore for a 1.0 release? Is this something that can be added later?

I believe this comment by @alexcrichton is solved with the new import rules in Rust 2018, right?

I imagine it could be hard for rustfmt to distinguish between internal/external crate imports, however :(, so it may not end up making it all the way through.

[daboross]

If I recall correctly, it was a conscious decision to not re-order import groups as there was no consensus?

https://github.com/rust-lang/rfcs/blob/master/text/2437-rustfmt-stability.md does allow for some formatting changes in minor version bumps so this could be included later.

[calebcartwright]

Understand why folks would like some prescriptions for this, but I don't see this ever coming to any kind of consensus and rustfmt simply won't have sufficient information to be able to do it well/cover everything.

We have introduced a new(ish), unstable, config option in rustfmt called group_imports that provides a non-default variant to support that std/external/crate regrouping. I'm skeptical that many (if any) other substantive groupings and variants will be possible, but motivated users should feel free to experiment and submit a PR to rustfmt with new variants/groupings for that option if they'd like something different

[gibfahn]

The group_imports option works great, thanks for adding it!

Is there an issue to track stabilising the option? I'm not in any rush, especially as you can configure rust-analyser to group imports, and to use nightly rustfmt, just curious as to how features progress from rustfmt nightly -> stable.

[calebcartwright]

The group_imports option works great, thanks for adding it!

Is there an issue to track stabilising the option? I'm not in any rush, especially as you can configure rust-analyser to group imports, and to use nightly rustfmt, just curious as to how features progress from rustfmt nightly -> stable.

rust-lang/rustfmt#5083
https://github.com/rust-lang/rustfmt/blob/master/Processes.md#stabilising-an-option

Stabilization of options is a different beast than the standard propagation of changes (config options or otherwise) from nightly -> beta -> release.

To be fully transparent, there's a number of outstanding issues afflicting the various import related options, and I doubt any of them will be candidates for stabilization any time soon