Jon Pretty

But it brings much more accessible syntax to something many programmers would not bother to write because it would be too verbose.

Which of the multiple syntax variations? "enum class" isn't shorter and "enum" hardly supports any Scala language "feature", e.g. methods.

enum List[+T] { case Nil; case ::(head: T, tail: List[T]) } vs sealed trait List[+T] case object Nil extends List[T] case class ::[T](hea...

Now implement one of List's methods. I'll wait.

implicit class ListMethods[+T](list: List[T]) { ... } But I think that's the point: an "enum" is closer to a pure ADT.

I think now we are deep into post-hoc rationalization. Yes, this enum impl is very poorly designed, but no, it doesn't have to be this way.

I'm not sure it is that way, if you read @odersky's original motivation. I totally believe that he added the feature reluctantly...

I'm also not convinced by them. But I'm unwilling to binarily call them a disaster before I've tried using them extensively.