I usually state a concern about implicit vs explicit and dislike implicit features in languages. I sort of always assumed that people could agree on whether a feature was implicit or explicit, but apparently that’s not the case. So, I’ll propose a definition or at least a litmus test.
Basically, implicit features are cases where the compiler can make optional choices without requiring a change in the local syntax of the code currently being compiled.
So, for example, foo(&s) being equivalent to foo(&*s) given fn foo(_: &str) and let s = String::new("hello");, makes autoderef an implicit feature. The idea being that you can’t know by looking locally at the code whether a dereference is happening or not.
However, let s = "hi"; being the same as let s: &str = "hi"; is not an implicit feature, because the compiler has no choice about the type of s.
So, given the post that’s referenced:
- Assignment in Rust having move semantics is half implicit.
a = b; always results in some form of assignment, but whether there’s a drop of a before the assignment is optional (therefore implicit). Copy types still ‘move’ but they don’t make b unusable after the assignment, which makes that implicit. Which, ironically, makes move the least implicit part of assignment in Rust.
- Capture clauses aren’t implicit for the same reason that
let s = "hi"; is not implicit, the compiler doesn’t have a choice about how to reason about the closure. As an aside, I suppose my issue with lacking a syntax for capture clauses is less about it being explicit and more about understanding which variable is captured in which way and not being able to change how something is captured.
- Based on some research, the only aspect of the
match heuristics that is implicit is that match foo { N => () } can be interpreted as N being a type or variable introduction based on whether N is currently in scope as a type or not. Though, at least there’s a warning about this.
And obviously, ? is not implicit, because not typing it results in the same code not compiling.
The question of whether this module proposal is implicit or explicit under this proposed definition seems to be purely based on whether the names of files are considered part of the syntax of the language. If it is, then this is explicit and if it’s not, then it’s clearly implicit because there is no syntactic representation required to add or remove a file from compilation.
In any case, I’d encourage you to decide on a concrete and useful definition for implicit vs explicit that you can use rather than simply ignore the concerns of users just because some of them use inconsistent definitions and therefore, time changes their perceptions of whether something is implicit or not. Because implicit vs explicit are useless as definitions if they change over time for the same features, without the features changing. And personally, I’d prefer to be more rigorous than that.
