Finalising Enumerations for Scala 3

Scala 3 Release Projects
37

First, apologies that I’m not acquainted enough with internals to speak about the serialisation aspects.|

This reply is w.r.t. fromOrdinal / toOrdinal / values being generated at all or not, as opposed to whether fromOrdinal is changed to be a total function.

@tpolecat Yes, and since we are talking about inverse here, I think it’s also weird to have ordinal defined. But as it stands that one exists on the concrete value, or not, depending on whether it’s a nullary constructed value.

I do believe that fromOrdinal, toOrdinal and values should uniformly exist (or not) across the whole data type iff it is a coproduct of nullary data constructors.

package enumz

object Test {
  def main(args: Array[String]): Unit = {

    println(Nope.A.ordinal) // This should not compile
    //println(Nope.B.ordinal) // ok, value ordinal is not a member of object enumz.Nope
    //println(Nope.values) // ok, value values is not a member of object enumz.Nope.
                         // Although class Nope is an enum, it has non-singleton cases,
                         // meaning a values array is not definedbloop

    println(Nope.fromOrdinal(0)) // this should not compile
    println(Nope.fromOrdinal(1)) // this should not compile, blows up at runtime
  }
}


enum Nope {
  case A
  case B(x: Int)
  case C
}

Internals aside, any alternative behaviour is at the very least very surprising. Hopefully this is not a controversial opinion at all?