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

Lint: Multiple inherent impls #414

Open
llogiq opened this Issue Oct 25, 2015 · 2 comments

Comments

Projects
None yet
4 participants
@llogiq
Collaborator

llogiq commented Oct 25, 2015

We may want to have a lint that checks for multiple inherent impls. Why those are not problematic from a language standpoint, they can split the implementation of a type and make the code harder to navigate.

The hardest part is that the lint needs some storage, namely a set of type names that already had inherent impls, but we already have examples of that.

@llogiq llogiq changed the title from Multiple inherent impls? to Lint: Multiple inherent impls Oct 25, 2015

@oli-obk

This comment has been minimized.

Collaborator

oli-obk commented May 31, 2018

We do have this lint now for non-generic impl blocks. The next step would be to make the lint trigger on any two impls blocks with the same generics.

@clarcharr

This comment has been minimized.

Contributor

clarcharr commented May 31, 2018

I do agree that this should apply if the impls are in the same file; it makes the most sense to me to replace impl bounds with where clauses on methods. That said, it also makes sense to be able to do multiple impls in multiple files— one example I've used is that the nibble crate has a separate module for implementing formatting traits and passing through inherent methods. The actual types are spread into multiple modules for readability but these impls are similar enough that it makes the most sense to use a macro.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment