Linting and match ergonomics

[oli-obk]

@phaylon

On the other end of the spectrum, mem::forget could probably use a lint for noop uses as well. Though I haven’t used that one in quite a while.

• forget_copy
• forget_ref

Both of which are scheduled to get uplifted together with drop_ref and drop_copy

@phaylon

I’m sometimes wondering, if we had started out with match ergonomics, would a lint requiring one to explicitly state the reference semantics be this contested?

Probably not Most of the defensiveness (at least from me) is a counter-reaction to the swath of "match ergonomics will destroy Rust, we must lint it away" messages that happened just after stabilization. Sorry that the bar has been raised, but I hope you can see why it happened.

@phaylon

Linting against ref mut bindings that aren’t mutated.

This so much. Warn by default in my book. Or we just fix the unused mut lint of rustc to detect this case

@phaylon

Linting against plain match ergonomics bindings on &mut values when nothing or only parts are mutated.

I'm wondering whether it would make sense to opt out if it is written as match &mut foo { .. }, since the user is obviously requesting it.

@phaylon

Linting against deref coercions, as mentioned above.

So I'm thinking we should have a further clippy category for defensive programming. According to the clippy 1.0 RFC this needs a further RFC. We can brainstorm it here in the internals forum. I'll fork the discussion from this post.

@phaylon

Here are some demonstrations of issues caused by match ergonomics. I hope these will suffice as demonstrations of the kinds of guarantees I’m after.

Thanks for doing this! Although I personally disagree that the examples are problematic (or more my opinion is that code on which such effects would be observable is problematic to begin with), I accept that

1. these examples are minified and contrived and the real code might be something that evolved and is just missing a refactoring that might not be in the budget right now
2. we should support defensive programming at any level of granularity
3. diagnostics still need some work