Lint trait impls whose body accesses `self.field` instead of `let Self { field } = self`

[oli-obk]

If the type is ever extended to contain more fields, the trait impl could be left behind and accidentally break the runtime behaviour. Using the let Self { field } syntax allows one to use a pattern that covers all fields (and ignores unneeded fields with field: _ explicitly).

In tandem the lint should complain about let Self { field, .. } and suggest to fill in other_field: _ patterns for the missing fields

[Centril]

In tandem the lint should complain about let Self { field, .. } and suggest to fill in other_field: _ patterns for the missing fields

This feel rather pedantic so I'd put it under a different category. The lint in general seems pedantic and not necessarily about correctness. I'd call it a "robustness lint" in the sense that it protects against future changes.

[Manishearth]

Yeah, this feels really pedantic to me, works as a restriction lint. I'm not sure why this focuses on trait impls either.

[Centril]

I do however see the appeal with rustc-developer coloured glasses. @Manishearth I wonder if there's a broader category of "refactoring friendly" lints that are a smaller set than the zoo of restriction lints? Such a category may include wildcard_enum_match_arm as well as lints against if let in favor of exhaustive match...