Where should `_` be allowed as an identifier?

[apblack]

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?

[KimBruce]

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.)

[IsaacOscar]

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.

[apblack]

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?