Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[unstable option] reorder_impl_items #3363

Open
Tracked by #83 ...
scampi opened this issue Feb 13, 2019 · 4 comments
Open
Tracked by #83 ...

[unstable option] reorder_impl_items #3363

scampi opened this issue Feb 13, 2019 · 4 comments
Labels
unstable option tracking issue of an unstable option

Comments

@scampi
Copy link
Contributor

scampi commented Feb 13, 2019

Tracking issue for unstable option: reorder_impl_items

@scampi scampi added the unstable option tracking issue of an unstable option label Feb 13, 2019
@scampi scampi changed the title [unstable option] unstable option: reorder_impl_items [unstable option] reorder_impl_items Feb 18, 2019
@sum-elier
Copy link

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
Copy link
Member

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
Copy link

AurevoirXavier commented Apr 27, 2022

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
Copy link
Member

Nemo157 commented Aug 21, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
unstable option tracking issue of an unstable option
Projects
None yet
Development

No branches or pull requests

5 participants