Rust-clippy: Lint request: Pattern match default binding modes / "match ergonomics"

[H2CO3]

Hey there!

I'd like to see a lint in Clippy that warns against uses of the relatively recent "pattern match default binding modes" feature, whereby, for example, you can match a reference against a non-reference type and have the equivalent of inserting */&/ref at the "correct" places.

I was very much against this feature (along with other Rust users who have been bitten by it), because it hides important information. I would like to have a compiler error when I try to match a pattern with a type that it isn't, as I always want to use the pre-"ergonomics" semantics.

Auto-deref in patterns for Copy types without field access or method call was also discussed on the internals forum and in GitHub issues, and (unsurprisingly) it seems to have been supported by the lang team, so it will potentially be added to the language in the future. Along with match "ergonomics", it could lead to even more surprising results in terms of types and copies. The ability to #[warn] against match ergonomics would mitigate these sort of problems as well.

A workaround would be to just use an older version of Rust that doesn't have match ergonomics, but then it would not be possible to use all the other new features and rely on bugfixes in newer versions. Hence, I think a lint against match default binding modes would be useful.

[Manishearth]

We've had similar proposals in the past for other features folks don't like. If it's an RFC'd feature we're not going to add lints that warn against its use unless there's a good reason. Sorry.

[H2CO3]

Er, there is a good reason: it introduced bugs in real people's real code. And it could be allow-by-default. The whole point of a linter is to be able to disallow things that compile but still can be dangerous.

[Manishearth]

You've got to be more descriptive than that.

AIUI the amount of hidden references introduced by match ergonomics is no more than many other features of Rust that work similarly. It's unexpected _now_, but I'd rather wait a while for the dust to settle before we mark things as unidiomatic. Historically there's been similar confusion around new features that settles down.

allow-by-default is still a judgement on idiomaticness. We're not going to mark an explicitly RFC'd feature (not an unfortunate consequence or interaction of a feature, the whole feature itself) as unidiomatic. Sorry.

If you have a more specific situation in which this is problematic we can lint about that. "Lint about this entire feature because it causes some problems" is unacceptable for clippy.

[H2CO3]

Now tell me then, how am I going to protect myself from the kind of bugs it introduces if not using a linter? I mean, my ultimate goal is not having clippy modified – rather, it's writing correct code, and have some sort of automated help ensuring that I do.

By the way, I don't care about judging a feature as idiomatic or unidiomatic – and to me, it doesn't seem like clippy is/was about that either. It contains many lints against code that is idiomatic yet most probably incorrect. There are – rightfully – lints against casting between integer types. That's a core language feature too, and sometimes necessary. But it mostly is a red flag.

[Manishearth]

Ask for lints that catch the kind of bugs it introduces.

Tell us what kind of bugs it introduces in the first place -- I'm not going to take your word on it.

We do not lint on comparisons just because some kinds of comparisons are buggy. We find the buggy comparisons (e.g. comparisons with NaN) and lint on them.

Similarly, we're not going to lint a feature away. We will lint the buggy cases of the feature.

It's becoming a reasonably common thing for people to come to clippy after a controversial RFC and ask for a lint reversing the RFC decision. I'm sorry, clippy doesn't work that way.