I’m not sure what this means, since clearly we don’t have the same argument?
I never explicitly stated what I wanted the lint to be, but the statement you quoted was meant to imply that I wanted something holistic and not limited to just ‘match ergonomics’. Note, the entire point of lints is to deny valid code and the entire point of having default allow lints is to let users pick whether they want to use that lint or not. I honestly can’t believe that we’re literally arguing about whether lints should deny valid use cases since that’s what they do by definition and can’t do anything else. All invalid use cases which can be efficiently detected are already compiler errors rather than lints.
As for the underlying problems with features like match ergonomics (I have similar issues with autoderef), at a high level is as follows. I remember Niko describing the motivation for autoderef (which has existed since before 1.0). He said that once he’d learned the language, having to type extra *s between & and exp was just busy work and so, it was decided to have the compiler do it for you. The oversight here (which may or may not be sufficient to override the decision, depending on the way you personally weight various things) was that part of the reason he learned the language and felt like the *s were busy work is because compiler errors are a teaching tool for the language. Something not compiling is a forcing function for reevaluating your mental model of the language. This means that whenever a potential syntactic construct can be valid or invalid, the potential for users to develop an inaccurate mental model of the language should be considered. Granted, it is hard to concretely account for this, way more so than it is to account for the number of users complaining about compiler errors and syntactic noise. Note, & and &mut when passing arguments to a function could be removed, C++ doesn’t require any additional syntactic noise when calling functions with a reference instead of a value, and yet, Rust decided that this noise was worth it. We may disagree about the weight of the problem and exactly where the line is on any given construct, but we should be able to understand that this spectrum exists.
Do people complain about the assign_ops lint? Do people even know it exists and if they used it, it would conflict with the assign_ops_pattern lint? Your objections aren’t grounded in the reality of a lint you yourself created and admitted to wanting to remove, but the lack of complaints meant that you not only didn’t remove it but you didn’t file an issue to remove it (and I assume no one else did). If the suggestion was for a deny or warn lint, I would understand the objection. But given the existing set of allow lints, I think you’re standing on quicksand by rejecting any lint that is worth multiple people spending hours merely discussing.
Are you suggesting that you want to make a breaking change to remove a lint from semi-official Rust project that would break users who depend on it without any evidence that people dislike it or want it removed?
Apparently my attempt at an example failed. Perhaps because I didn’t add enough context. My motivation for the example was some experience working on lalrpop and migrating from using the custom string interner to using one from servo (I think). The new one didn’t implement copy, so various value bindings needed to become reference bindings. It turns out there are matches all over lalrpop that involve interned strings. I suppose you would suggest that match ergonomics would result in correct code while not requiring me to have changed as much of it directly. And in this case, that’s true. But interestingly, I learned a lot about matching and bindings from changing that code and additionally, when I was done, I had high confidence that I knew what it did. If match ergonomics were available at the time, do I think the code would’ve become incorrect in some way? No, probably not. Can I imagine a scenario where the code (ignoring unsafe) would become incorrect with match ergonomics in play? Not really. The more I consider it, the more I realize that incorrect code isn’t the point. The primary reason I’m able to currently reason about how match ergonomics would impact that change is because I needed to type it out explicitly at the time. I simply wouldn’t have learned as much without the compiler complaining and having to search the source for every location and therefore learning even more. And that’s ignoring the fact that the process gave me confidence that the code was right. If having a lint (regardless of the specific cases) can result in bringing that possibility for learning/confidence back to the language, I’d vote yes.
