Open apblack opened 4 years ago
I believe the only reason to allow it in a declaration like
def _ = exp
is to force the evaluation of exp for its side-effect. However, we already allow that by just writing
exp
on a line by itself. Thus I don't see any reason to allow it. (Languages with pattern matching like ML and Haskell allow it on the left sides of def statements, but we don't do that pattern matching.)
There are several cases where I would use '_':
import "mod" as _ // for the side effects of initialising "mod"
for (a) do { _ - > e } // do 'e' once for each element of 'a'
type Set = interface {
contains(_) // because parameter names are ignored anyway...
... }
class empty_set {
// needs a parameter to conform to the set type,
// but we don't actually use it
method contains(_) {
false }}
I can't think of any reason why I'd use it as a method, def, var, or type name.
On a side note, I notice that rust doesn't allow _
as a parameter name but only as a pattern. However starting a parameter/variable/function name with an _
will suppress any "unused variable" warnings.
I've also used _
in an import; it makes clear that the imported object is not used. I've added a comment to explain that the import was there fo its effect.
That use, and the use as a parameter name, seem to be the only ones. Should we restrict its use to those places? This makes the language definition a wee bit longer. Is there any gain?
In minigrace issue #322, @Isaac observes that there is no utility in using
_
as an identifier for anything but parameters.I don't recall what languages we were following when we allowed
_
as an identifier. Is it in fact useful in any other place? Should we restrict_
to parameter positions?