java style enums should not allow mixins in cases

[bishabosha]

Minimized code

There is no syntax for an individual java enum case to implement a new interface, e.g. the following is an error

public enum Foo {
  Red implements java.util.Function<Integer, Boolean> {
    public Boolean apply(Integer i){
      return i > 3 ;
    }
  },
  Green,
  Blue
}

Note: you can make a Java enum case as an anonymous subclass, it just can't add new parents to what the enum already implements. e.g.

public enum Foo implements java.util.Function<Integer, Boolean> {
  case One {
    public Boolean apply(Integer i){
      return i == 1 ;
    }
  }
  case Two {
    public Boolean apply(Integer i){
      return i == 2 ;
    }
  }
}

Expectation

so therefore the following should be an error in dotty:

object FancyColours {
  sealed trait Pretty { self: Colour => }
  sealed trait Dull { self: Colour => }
  enum Colour extends java.lang.Enum[Colour] {
    case Pink extends Colour with Pretty
    case Red extends Colour with Dull
  }
}

This prevents any optimisation of typing java enums as an EnumTag Constant

[anatoliykmetyuk]

What are the implications of allowing inheritance of Scala 3 java-compat enum cases?

[bishabosha]

I don't think it should cause any issues in java, it just means you can't type it as if it were a java enum, e.g. there is an optimisation in Scala 2 that for java enums just uses the symbol of the parent class for all type checking

[anatoliykmetyuk]

Does that mean we'll get issues with Scala 2 interop if we allow this flexibility?

[bishabosha]

This was opened just to decide on what it means to be java style enum from a static type point of view, as in Scala, Constants referring to Java enums compiled by Java make optimisations that forgets any precise type

[bishabosha]

this wont cause problems in scala 2 compat either way

[anatoliykmetyuk]

If the situation doesn't cause any problems but changing it might, why try to change it?

[bishabosha]

Overall, I think that unlike #7499, it is safe to allow mixins for individual cases because the enum API is all final and defined in java.lang.Enum, and does not check interfaces of runtime classes. As a benefit, mixins can actually be used to provide the behaviour that java allows with anonymous subclasses for enum cases:

trait OneImpl extends (Int => Boolean) {
  def apply(v1: Int): Boolean = v1 == 1
}
trait TwoImpl extends (Int => Boolean) {
  def apply(v1: Int): Boolean = v1 == 2
}
enum Foo extends java.lang.Enum[Foo] with (Int => Boolean) {
  case One extends Foo with OneImpl
  case Two extends Foo with TwoImpl
}