Disallow _ as an identifier

[szeiger]

Currently the lexical syntax allows a single underscore _ as a valid identifier because it is treated as an upper-case character. This leads to inconsistencies in the syntax because in many (but not in all) contexts the underscore has special meaning and is therefore not a valid identifier:

val _ = 1 // Identifier, even though it could also be a simple pattern
var _ = 1 // The same
def _ = 1 // Syntax error
println(_) // Eta expansion

Implicit vals are a dangerous corner case where the difference between an identifier and a simple pattern becomes important:

implicit val (_, _) = (42, "foo") // _ treated as simple pattern
implicitly[Int] // Does not compile

implicit val _ = 42 // _ treated as identifier
implicitly[Int] // returns 42

I propose to change the lexical syntax so that a single underscore is no longer a valid identifier (unless it is enclosed in backticks). When used in a val or var definition it should be treated as a simple pattern (in the way in which is is already specified).

[propensive]

As another datapoint, _ is also valid as a "don't care" identifier in a lambda, e.g. List(1, 2, 3).map { _ => println("foo") }.

[som-snytt]

Underscore is lower case. scala/scala#5919

It's underscore, not upperscore or overscore.

Also #6426

I was going to say:

$ scala
Welcome to Scala 2.11.8 (Java HotSpot(TM) 64-Bit Server VM, Java 1.6.0_65).
Type in expressions for evaluation. Or try :help.

scala> object X { val _ = 42 }
defined object X

scala> { import X._ ; 42 match { case x @ `_` => x } }
exception when typing <_: error>.==(x1)/class scala.reflect.internal.Trees$Apply
not found: value _ in file <console>
scala.reflect.internal.Types$TypeError: not found: value _

but I guess I won't. (The import is not relevant to the crash.)

Wasn't there a movement underfoot or perhaps a motion for underscore to introduce a fresh name? with caveats around stability of member names. I may be conflating underscore with the consultancy.

implicit val _: Int   = 42 // implicitly[Int] is $x1
implicit val (_): Int = 42 // introduces nothing
implicit val _: _     = 42 // escape hatch for unproblematic typing?

They're going to make us supply types of implicits, must we supply names, too?

[szeiger]

Wasn't there a movement underfoot or perhaps a motion for underscore to introduce a fresh name?

Using underscores to not introduce a name is essential for un-imports and very convenient for pattern matching. You wouldn't want to bind lots of vals you don't care about. For consistency it would be nice to get the same behavior in other cases as well, rather than introducing fresh names (or binding to _).

As another datapoint, _ is also valid as a "don't care" identifier in a lambda, e.g. List(1, 2, 3).map { _ => println("foo") }

In Scala 2.12 this doesn't bind to _:

scala> val f: (Int => Int) = { _ => `_` }
<console>:11: error: not found: value _
       val f: (Int => Int) = { _ => `_` }

For some reason Dotty doesn't like a quoted _:

scala> val f: (Int => Int) = { _ => `_` }
-- Error: <console>:1:29 -------------------------------------------------------
1 |val f: (Int => Int) = { _ => `_` }
  |                             ^
  |                             wildcard invalid as backquoted identifier

But by writing an implicit function we can observe that the implicit parameter is indeed bound to a name:

scala> val f: (Int => Int) = { implicit _ => implicitly[Int] }
val f: Int => Int = $$Lambda$10/479160976@3050ac2f

[szeiger]

BTW, accidental assignment to _ also breaks the REPL:

No problem here:

scala> { val _ = 42 }

Here the REPL tries to create code to print the result (and fails):

scala> val _ = 42
<console>:5: error: identifier expected but '_' found.
  lazy val $result = _
                                          ^
<console>:10: error: identifier expected but '_' found.
 + "_: Int = " + _root_.scala.runtime.ScalaRunTime.replStringOf(_, 1000)
                                                                                     ^

[dwijnand]

In case it is decided not to disallow _ as an identifier I extracted the REPL bug into it's own issue: #10645.

[Atry]

But by writing an implicit function we can observe that the implicit parameter is indeed bound to a name:

scala> val f: (Int => Int) = { implicit _ => implicitly[Int] }
val f: Int => Int = $$Lambda$10/479160976@3050ac2f

@szeiger Is it possible to extend this behavior to support implicit def as well?

object Implicits {
  // Generate a term name from the method type
  implicit def _: Ordering[BigInteger] = ???
}

import Implicits._
implicitly[Ordering[BigInteger]]

[som-snytt]

The canonical ticket is #7691

The anon fun syntax is covered by 6.23, which says you get a fresh name for underscore; but it doesn't include implicit underscore; maybe that was added by popular demand?

The other "fresh name" semantics is what I asked about in a previous comment. Maybe that will also succumb to popular demand. After the # metoo movement, I believe that the people have the power.

[Atry]

For public methods, "fresh name" may be not a good idea to keep backward compatibility. Hash naming based on the method type may be a better choice.

[som-snytt]

I submitted a fix at #7691

I think most of the info is on the other ticket?

[xuwei-k]

FYI com-lihaoyi/fastparse#214

[SethTisue]

@som-snytt should this ticket still be open?

[som-snytt]

@szeiger might have another idea, but I think the edge cases were covered in some form:

scala> implicit val _ = 42 ; implicitly[Int]
                                       ^
       error: could not find implicit value for parameter e: Int

scala> def _ = 1
           ^
       error: identifier expected but '_' found.

scala> val f: (Int => Int) = { implicit _ => implicitly[Int] }
                                        ^
       error: expected start of definition

I think the speculative part about using underscore to introduce anonymous implicits is still an open issue, but deserves its own ticket if there isn't one. Also, to extend the metaphor, for for:

scala> for (implicit _ <- List(42)) yield implicitly[Int]
            ^
       error: illegal start of simple pattern

Also, arguably implicit should error if nothing is bound. If it doesn't throw, then normally the implicit is available:

implicit val Extractor(x) = expr   // either succeeds and implicit is available or throws MatchError