Add a static ordinal method to non-singleton enum cases

[harpocrates]

In a nutshell: it should be possible to extract the ordinal associated with all cases of an enum, even if they aren't singletons. Right now, this is only possible to do with an instance on hand.

enum Opt[+T] {
   case Sm(x: T)
   case Nn 
}

@main
def main = {
  println(Opt.Nn.ordinal)
  println(Opt.Sm.ordinal)  // This won't work
  println(Opt.Sm(1).ordinal)  // This will work
}

The change needed is pretty trivial too: for the final case class's generated in Translation of Enums and ADTs: case 9, we make sure that the class also contains a static ordinal method as well as an instance method.

Additional motivation

This would enable future optimizations, eg. to support translating match on enum into a lookupswitch/tableswitch (as Java does). The usual trick there is to build up a static array of switch integer labels using ordinals in the match, and then switch on the value found in this array at the index of the scrutiny's ordinal (unfortunately this is the best online description I could find, although this can also be inspected pretty easily by inspecting the bytecode produced by Java code switching on an enum). That static array can't be constructed if the ordinals for the cases aren't also statically queryable.

[harpocrates]

Provided there aren't any objections, I'd be happy to implement this small feature. I understand that something like the full optimization of match on enum is not going to make it into the initial Dotty release, but it would be nice to have all the necessary pieces in place to enable optimizations in future releases.

[bishabosha]

I am not sure of the use case you need a static method for, because in pattern matching the instance ordinal method will be available

[harpocrates]

@bishabosha are you sure? Here's the elaborated desugaring I had in mind. Please let me know if you see how I would do this efficiently without a static method. I get that it is really tempting to just switch on the ordinal method directly, but then you become reliant on the order of the enum cases and changing this order risks breaking match's (usually in transitive reverse dependencies that haven't recompiled against the latest version of the enum).

Initial code

enum Expr {
  case Literal(i: Int)
  case Add(lhs: Expr, rhs: Expr)
  case Minus(lhs: Expr, rhs: Expr)
  case If(cond: Expr, ifNonZero: Expr, ifZero: Expr)
}

def eval(e: Expr, context: Map[String, Int]): Int = 
  e match {
    case Expr.Literal(i) => i
    case Expr.Add(lhs, rhs) => lhs.eval() + rhs.eval()
    case Expr.Minus(lhs, rhs) => lhs.eval() - rhs.eval()
    case Expr.If(cond, ifNonZero, ifZero) => if (conf.eval() != 0) ifTrue.eval() else ifFalse.eval()
}

Scala pseudo-code for the desugaring

// this class needn't be statically defined - it could be a `Lookup::hiddenClass` from an `invokedynamic` 
class eval$matchMap$Expr {
   @static
   val matchCases = {
     val c = new Array[Int](4) // initial all zeroes
     try { c[Expr. Expr.Literal.ordinal()] = 1 } catch { case _: NoSuchFieldError => /* skip */ }
     try  { c[Expr.Add.ordinal()] = 2 } catch { case _: NoSuchFieldError => /* skip */ }
     try  { c[Expr.Minus.ordinal()] = 3 } catch { case _: NoSuchFieldError => /* skip */ }
     try  { c[Expr.If.ordinal()] = 4 } catch { case _: NoSuchFieldError => /* skip */ }
     c
  }
}
  

def eval(e: Expr, context: Map[String, Int]): Int = {
  (eval$matchMap$Expr.matchCases[e.ordinal]: @switch) match {
    case 1 =>
      val Expr.Literal(i) = e.asInstanceOf[Expr.Literal]
      i
    case 2 =>
      val Expr.Add(lhs, rhs) = e.asInstanceOf[Expr.Add]
      lhs.eval() + rhs.eval()
    case 3 =>
      val Expr.Minus(lhs, rhs) = e.asInstanceOf[Expr.Minus]
      lhs.eval() - rhs.eval()
    case 4 =>
      val Expr.If(cond, ifNonZero, ifZero) = e.asInstanceOf[Expr.If]
      if (conf.eval() != 0) ifTrue.eval() else ifFalse.eval()
    case _ => throw new IncompatibleClassChangeError() // an enum case got added without recompiling `eval`!
}

[som-snytt]

Isn't it accepted that enum ordering is API and you can't muck with it?

[harpocrates]

Isn't it accepted that enum ordering is API and you can't muck with it?

I don't understand this comment. Yes, the values outputted by ordinal could definitely change across recompilation. Ideally they don't too much, but they will probably change at least when you add/remove/re-order. The whole point of my request is to enable efficient match desugaring that is resistant to this change.

Java's enum can also change ordinal values as a result of adding/removing values (maybe even re-ordering?) but because they use this translation strategy for switch statements and expressions, binary compatibility can be maintained (see 13.4.26. Evolution of Enum Classes).

[som-snytt]

Sorry, middle of the night here and I said the opposite thing. Ordinal is what you don't rely on to be stable. Java enum serialization uses the name, for example.

[harpocrates]

I understand that the ordinal is unstable, but the name is not a good switch target (the JVM switches on ints, not strings). Does the sample desugaring of how we might efficient compile a match on enum make sense? Again, this isn't a new discovery: it is just the sensible efficient thing from Java that I think Scala should not throw away.

Although you shouldn't serialize the ordinal directly, you could play a similar desugaring trick (list out the variants in an array that is dynamically populated) to derive some locally stable ordering.

[rssh]

+1.
// theme on contributors forum: https://contributors.scala-lang.org/t/access-to-enum-adt-ordinal-in-absence-of-case-instance/5290. )