[unstable option] `group_imports`

[karyon]

Tracking issue for unstable option: group_imports.

See Processes.md, "Stabilising an Option":

• Is the default value correct?
• The design and implementation of the option are sound and clean.
• The option is well tested, both in unit tests and, optimally, in real usage.
• There is no open bug about the option that prevents its use.

[stjepangolemac]

Would it be possible to add a fourth group for the workspace members? They're technically external crates but still different from 3rd party crates. Something like StdExternalWorkspaceCrate.

(let me know if this isn't the right place to discuss this)

[calebcartwright]

No worries @stjepangolemac fine to ask here (and probably worth having pointers to various issues anyway). In short, we're limited by the information that's actually available. More detailed in the issues linked below

rust-lang/style-team#131 (comment)
#4693
#4709

[ShadowJonathan]

What's preventing the option from stablising as-is? #4693 to me seems to be about the addition of an extra option, but is there any problem with the current options? Any real bugs?

[daboross]

#4709 seems like a fairly big bug to me. Besides that, did we actually decide that this was the only sane ordering? I'm pretty sure it was waiting on having a few different options for grouping imports before stabilizing, if it is ever going to stabilize.

[calebcartwright]

I appreciate the interest and willingness of folks to participate in discussions, but should you choose to do so, a gentle reminder to be sure to thoroughly read the thread and linked material.

The process for stabilizing an option is both linked, and enumerated with checkboxes, in the issue description. None of those enumerated requirements can be cleared yet, including the fact that yes there's indeed real bugs that are either directly linked or transitively linked from issues/discussions that are directly linked. One can also search open issues to find additional related issues that aren't directly linked.

To again echo inline:

• All import options, including this one, have a number of issues with comments that prevent stabilization
  • Clarify recommended ordering of groups, even without rustfmt support? style-team#131 (comment)
• The rustfmt team has no intention of working on any other variants for this option, and it's one that will remain disabled by default. We continue to be skeptical that any additional variants are even practical, and stabilization of the option unequivocally does not hinge on additional variants. The fact that others would like the option to have more powerful variants is understandable but that desire doesn't change the underlying visibility/availability of data problem.
  • Clarify recommended ordering of groups, even without rustfmt support? style-team#131 (comment)
  • group_imports does not differentiate between a local import and an external crate #4709 is not a bug as mentioned and discussed on that thread, but a case where people want more and where more might not be possible.
• Anyone's welcome to attempt to implement a new variant, and should that occur after the option is stabilized, then the new variant would be "unstable" and only available on nightly until such time as it could clear the standard set of criteria

[SimonSapin]

I’d like for this option to have another value named Visibility that makes one group for use example;, one for pub(crate) use example; and another for pub use example;. (I’m less sure of the groups’ order.)

This is to separate private imports (that are only there for convenience of naming things inside a module’s code) from reexports that affect the public API of a module or crate.

[calebcartwright]

Seems I forgot to hit the "comment" button the other day, but yes @SimonSapin that type of grouping and variant should be possible with the information available to rustfmt.

However, I think it would be best to pull this additional-variant request out so it can be tracked as a separate feature requests, both for work tracking/implementation purposes and because it's not necessary for stabilization of the option nor related to it (we have the ability to add new, unstable variants to already stable options)