Simplify Enums

[odersky]

I had a lingering unease that the rules for enums were too complex, and the syntax too cumbersome. I now think I have found a way to simplify things considerably. The key was to take away one capability: that cases can have bodies which can define members. Arguably, if we choose an ADT decomposition of a problem it's good style to write all methods using pattern matching instead of overriding individual cases. So this removes an unnecessary choice. What's more, once we have eliminated case bodies we also have eliminated scope confusion. All that remains are the case parameters and extends clause. Extends clauses of cases can be handled like super-calls in constructors: I.e. the enclosing enum class is not visible for them.

This means we can treat enums unequivocally as classes. They can have methods and other statements just like other classes can. Cases in enums are seen as a form of constructors. We do not need a distinction between enum class and enum object anymore. Enums can have companion objects just like normal classes can, of course.

This also means that type parameters of enums scope naturally over cases, just like they scope
over secondary constructors. We do not need to repeat them in cases anymore, which is a huge relief.

This first commit changes the syntax, docs and tests. It still needs to be implemented.
So tests should fail right now.

[odersky]

I think this is done now. In summary, the syntax is much nicer and the changes in parsing and translation were straightforward. The tough part was to implement this rather vague idea that enum cases are treated like constructors for scope checking. The details of this turned out to be very tricky. This goes to show that some things are easy in the sense of "intuitive" but really hard to drill down.

The previous scheme was comparatively non-intuitive (since we needed explicit enum classes and objects) but much easier to check.

[allanrenucci]

I tried the code below and was surprised it didn't compile. Is it indented?

object E4 {
  type INT = Integer
  val defaultX = 2
}

enum E4 {
  import E4._

  case C1(x: INT) // error: illegal reference
  case C2(x: Int = defaultX) // error: illegal reference
  case C3[T <: INT] // error: illegal reference

  def bar: INT = defaultX // But this is OK?
}

[liufengyun]

The check in checkEnumCompanions is a little too strict, maybe we should use a context that already have the stats indexed in the checking?

enum Color(val x: Int) {
  case Green  extends Color(3)
  case Red    extends Color(2)
  case Violet extends Color(Green.x + Red.x)        // error
}

object Test {
  abstract class Color(val x: Int)
  case object Green  extends Color(3)
  case object Red    extends Color(2)
  case object Violet extends Color(Green.x + Red.x) // ok
}

[liufengyun]

It seems ctx is not actually the context (which contains class members) used in checking member definitions, thus the following code fails the check:

enum Color(val x: Int) {
  case Green  extends Color(3)
  case Red    extends Color(2)
  case Violet extends Color(Green.x + Red.x)        // error
}

Is this intentional?

Edited: I was wrong, it's the right context, the problem is that when we checkEnumCaseRefsLegal for Color$, it checks Green.x + Red.x, of course it cannot be resolved!

[odersky]

Yes, I think we need a refinement here. This accessibility checking is quite a can of worms.

[odersky]

I tried the code below and was surprised it didn't compile. Is it indented?

Yes, that's as intended.