[unstable option] reorder_impl_items

[scampi]

Tracking issue for unstable option: reorder_impl_items

[sum-elier]

Should reorganized elements maintain their original order?

Example:

pub trait MyTrait {
    type c;
    type b;
    type a;
}

So after formatting instead of this:

impl MyStruct for MyTrait {
   type a = ();
   type b = ();
   type c = ();
   ...
}

we have this:

impl MyStruct for MyTrait {
   type c = ();
   type b = ();
   type a = ();
   ...
}

[calebcartwright]

Should reorganized elements maintain their original order?

The current behavior is intentional, though whether that's ultimately desirable is a different question. It's possible we my need something along the lines of what we have for imports with group_imports and reorder_imports that provides more flexibility and differentiation between sorting of the elements of the same type vs. moving elements of the same type into their respective, ordered groups

[AurevoirXavier]

Should reorganized elements maintain their original order?

Example:

pub trait MyTrait {
    type c;
    type b;
    type a;
}

So after formatting instead of this:

impl MyStruct for MyTrait {
   type a = ();
   type b = ();
   type c = ();
   ...
}

we have this:

impl MyStruct for MyTrait {
   type c = ();
   type b = ();
   type a = ();
   ...
}

What you expect is a sort.
I like the current implementation, which is good for code review.

[Nemo157]

I would also prefer if reordering of trait impls follows the order of the trait definition (at least for locally defined traits). I have a case where there are multiple types in a trait with a specific order because of relationships between them, but rustfmt reorders them in impls into alphabetical order making that relationship less clear.

EDIT: There's even a trait in core that shows how alphabetic ordering is less readable, the "correct" order according to rustfmt, while I at least much prefer this retaining the standard Item, IntoIter order:

impl IntoIterator for Foo {
    type IntoIter = FooIter;
    type Item = ();

    fn into_iter(self) -> FooIter {
        FooIter
    }
}

Given it's probably not really wanted to reorder items based on the order defined by external code (since that's dependency version specific), I guess my preference would just be splitting grouping and sorting into separate options so I can have the grouping without sorting.