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

New lint: prefer inlined or un-inlined associated types #14083

Open
clarfonthey opened this issue Jan 27, 2025 · 0 comments
Open

New lint: prefer inlined or un-inlined associated types #14083

clarfonthey opened this issue Jan 27, 2025 · 0 comments
Labels
A-lint Area: New lints

Comments

@clarfonthey
Copy link

What it does

This would be a pair of lints, likely under the restriction lints group (and thus allowed by default). The idea would be to check for whether non-generic associated types are inlined into definitions or not.

For example, this is the "inlined" style:

impl Iterator for MyType {
    type Item = u32;

    // note: u32 instead of Self::Item here
    fn next(&mut self) -> Option<u32> { /* ... */ }
}

And this is the "non-inlined" style:

impl Iterator for MyType {
    type Item = u32;

    // note: Self::Item instead of u32 here
    fn next(&mut self) -> Option<Self::Item> { /* ... */ }
}

Note that the scope for this would be very limited, only checking for trait methods. Otherwise, it's ambiguous what to do in cases like:

impl MyType {
    fn peek(&self) -> Option<<MyType as Iterator>::Item> { /* ... */ }
}

Here, since this is an inherent method, it's unclear whether this type should be inlined or not (replaced with u32), and the decision is left to the author.

Advantage

Advantages to the inline style:

  • The syntax can get very messy after nesting (e.g. <<MyType as MyTrait>::AssociatedType as OtherTrait>::Item)
  • It's immediately clear what the actual type is for all signatures

Advantages to the non-inline style:

  • They always match the trait definition, so, you know why a particular type is being used
  • The inlined type is not always shorter (especially if the type in the struct definition itself is from a trait's associated type)

Advantages to both styles:

  • The result becomes what's shown in rustdoc, so, the benefits of the style gets propagated to the documentation

Drawbacks

  • This lint could definitely be annoying if it doesn't have an auto-fixable version, since it can affect a very large portion of the code.
  • rust-analyzer tends to prefer the inline style when autocompleting, so, that would likely have to be modified to respect the lint.

Example

I am not bound by your issue template, and I already included an example. I'm not repeating myself.

@clarfonthey clarfonthey added the A-lint Area: New lints label Jan 27, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-lint Area: New lints
Projects
None yet
Development

No branches or pull requests

1 participant