Proposal for Multi-level Enums

Language Design
5

Good idea. This should work for inference since nested parameterized enum nodes aren’t case classes like their siblings. We want to avoid this type inference problem.

That said, is the current implementation of enums necessarily flat? Since the top-level enum is sealed rather than final, couldn’t we could already do something like the following?

enum JsValue { // desugars to a sealed abstract class
  case Obj(fields: Map[String, JsValue])
  case Arr(elems: ArraySeq[JsValue])
}
enum Primitive extends JsValue {
  case Str(str: String)
  case Num(bigDecimal: BigDecimal)
  case JsNull
}
enum Bool(boolean: Boolean) extends Primitive { 
  case True extends Bool(true), 
  case False extends Bool(false)
}

(Granted, the nested version is an improvement that’s easier to read and keeps all the types contained under the top level enum, and enumTag might not be built to handle this gracefully. If we did this, enum should probably also imply final)

2 Likes