Proposal for Enumerations in Scala

[eyalroth]

@julienrf

My (short) experience so far is that using the enum syntax to define ADTs does not work very well. As soon as you add methods to the enum it feels really weird to have them defined at the same level as enum constructors:

I had a similar feeling when trying to convert one of my ADTs (that has methods) to an inner-class-like syntax. I posted about it the other day on the multi-level enum thread. I could perhaps imagine a syntax like the following, which has nothing to do with enums:

sealed trait Json {
  def decode[A](using decoder: Decoder[A]): Option[A] = ...
  sealed {
    case class Bool(value: Boolean) { ... }
    case class Array(items: Seq[Json])
    case object Null
  }
}

We can play around with the keywords, but I think that two things are essential here:

1. Using case class and case object. This would (a) make it clearer that one is actually a class and the other is an object, and (b) allow for other class-def modifiers – final, private, etc – to be integrated seamlessly.
2. Nest / indent the nested ADTs under a certain keyword (not necessarily sealed).

@odersky

About adding methods to enum cases: I believe that should not be supported. The idea of an ADT is that it’s data ! If one wants a more OO approach where methods go with subclasses, then indeed one should use a sealed trait with subclasses.

I suspect that this would lead to developers using data-only ADT syntax with extension methods (like here) instead of OOP classes. Not to say that this is a bad thing, but just a consideration to be aware of.