I'd like to suggest that this thread will likely be more constructive if it carefully avoids rehashing arguments for or against "default binding modes". The proposal that started this thread was a request for a lint, not a request to change the default or to change how we teach Rust.
The existence of restriction lints in clippy does indeed make an excellent argument for this kind of thing. Such lints exist to help people enforce preferences on a codebase, and in particular, often to provide extra compiler guardrails to help people.
For instance, there's an allow-by-default lint for
as conversions, so that people can use a different kind of conversion; that's useful for code that might otherwise do many such conversions, to steer towards safer alternatives. We have the
default_numeric_fallback lint, which will lint against
let x = 5 without specifying a type; that seems like a similar "lint against compiler inference and make the code be more explicit". We have clippy lints for AT&T vs Intel asm syntax, so that projects can enforce a single preference. We have lints that will trip if you ever call
x + y rather than using a method like
checked_add; obviously many codebases will not want that.
None of these lints cause any kind of damage or bifurcation in the ecosystem. It's uncommon to even come across a project that uses them, but the projects that use them are grateful for the additional compiler support.
"Default binding modes", in particular, seem to provoke very strong reactions in many people. As far as I can tell, people who have argued against the lint when it has come up (in several threads, not just this one) are not making an argument about their own code; they're making an argument about other peoples' code, and in particular, arguing that tools should not make it easier to write such code even if people want to. That implies we're actively trying to discourage such code.
We do, sometimes, take steps to deprecate and discourage certain code patterns, and sometimes eventually remove them when there's a good reason to do so. When we do that, we provide lints against them, and migrations towards preferred approach, and similar. We use editions to make sure that old code still works, but we steer people towards one approach or away from another.
But we haven't done that for "default binding modes". It's been proposed, and the lang team discussed it; the current sentiment is not in favor of doing so. (For context, I was one of the people who argued against doing so, but not the only person.) The option to write code that doesn't use default binding modes is not going away.
I think if we take the arguments against the lint to be strong enough to decline to add such a lint, those arguments would also support deprecating non-"default binding modes" patterns (e.g.
And conversely, I think if we're not deprecating non-"default binding modes" patterns, there's no fundamental reason we shouldn't add a lint to support people who wish to use them.