Scala 3 - Should variables name format have same semantics?

Language Design
1

Variable start with uppercase is a stable identifier in scala 2 pattern match:

def f(x: Int, Y: Int): Boolean = {
  x match {
    case Y => true
    case _ => false
  }
}

If we drop this syntax in scala 3, we can still write the following to achieve the same functionality:

def f(x: Int, Y: Int): Boolean = {
  x match {
    case `Y` => true
    case _ => false
  }
}
2

Arguably, the special case is the “variable pattern”, where the identifier is a “variable identifier” because it starts with a lower case. This is subtle:

case r =>
case r() =>

One alternative is to go the other way:

def f(x: Int) = 42 match { case x => } // test x.==

The binding syntax

def f(x: Int) = 42 match { case y @ _ => }

could be simplified to

def f(x: Int) = 42 match { case y@ => }

since the underscore can be inferred. Then at-sign seems to say, bind this y. The penalty here of the suffix at-sign is less than the two back-ticks currently incurred for stable identifier.

I hope they also allow omission of underscore in

def f(x: Int) = 42 match { case if x > 0 => }

I don’t know when I soured on underscore, but possibly when I started doing:

42 match {
  case x if x >= 27 => false
  case ____________ => true
}

I don’t actually do that any more.

1 Like
3

the identifier is a “variable identifier” because it starts with a lower case

Why not all valid variable name is “variable pattern”, except we explicit it’s a “stable identifier pattern”

4

We know val x = 42 introduces x.

It may be less obvious for case r(x) or case C(c).

This is obviously different: case r(x@).

I hope I did not just argue for: val x@ = 27.

I agree it could go either way. Previously, I contributed case X @ p where the identifier can even be backticked.

The current rule was intended to be convenient and natural, yet it requires explanations and workarounds. Why is that?