Why do these two things have to be in conflict? I'm disappointed to see this assumption unchallenged.
"Be explicit about everything ever" was never a goal of Rust. We often tried to err on the side of explicitness when we weren't sure what to do, or when we knew that overly implicit behavior caused real problems in other languages (e.g. super-liberal numeric conversion in C). But there have been plenty of instances where we added inference and it made a huge difference in the expressivity of the language. A couple of examples that most people here likely don't remember:
-
Moves based on type. You used to have to write
movebefore values when moving them. This was tremendously inconvenient. The idea of implicitly moving was incredibly controversial; a lot of people thought it wouldn't work at all. But nowadays nobody questions it. -
Capture clauses. You used to have to explicitly choose whether to capture all variables by value, by immutable reference, or by mutable reference. This added a lot of verbosity to closures. People thought that inferring captures was out of the question, but it actually turned out to really enhance the usability of the language.
-
Nullary-enum-variant/variable disambiguation. It may be hard to believe now, but to deal with the ambiguity between
match foo { None => ... }andmatch foo { x => ... }, you had to write.after enum variants: so for example you would writematch foo { None. => ... }. If you didn't do this, the compiler would thinkNonewas a new variable binding and you'd get a confusing error. When I proposed just inferring, people swore up and down that this would ruin the language, that the compiler complexity would mushroom, that it would be incredibly confusing, etc. etc. None of this happened, and nowadays the controversy is entirely forgotten.
The lesson of history, to me, is that people worry a lot about implicit behaviors, but as long as thought is put into the design and lessons from the implementation are taken into account bad interactions rarely happen.