fix #7227: allow custom toString on enum

[bishabosha]

fixes #7227

productPrefix is now overridden using the enum constant's name and used in the by-name lookup in runtime.EnumValues.

enumLabel is added as an abstract method to scala.Enum and implemented using the enum constant's name. productPrefix is also overridden in concrete enum values to point to enumLabel, as it is used to implement string lookup of enums.

We then also add a default toString to an enum value implementation if an override is not provided in the parent class

java based enum values are optimised so that productPrefix and enumLabel will
forward to this.name in the simple enum case, avoiding an extra field

[TheElectronWill]

I find productPrefix much less user-friendly than name, especially since the latter is familiar for users coming from Python, Java, Kotlin and probably more. It can also be surprising that name is the only method that requires extends java.lang.Enum to be available. You can call ordinal, productPrefix, etc. on all enums but not name.

Could name be handled in a similar way to toString, i.e. redirect to productPrefix for pure-dotty enums and to the name method for java enums?

[bishabosha]

@TheElectronWill name is more tricky to add to all enums, for example:

enum User:
  case Basic(name: String)
  case Unknown

we won't be able to define a field name for Basic if we want name to always be the identifier it was declared with, whereas productPrefix is not likely to clash with a field name

it could potentially be added to concrete enums if they have no parameterised cases, but then that API is again not generic unless we make a new mixin trait.

We can definitely explore options though, like do the above and have an annotation to force checking of only value cases, or a type class that adds an extension and does the same checking

[TheElectronWill]

Doesn't ordinal have the same problem as name? Maybe the real problem is that name is too common to be reserved by the language, and caseName or rawName (or enumName?) would be better.

[bishabosha]

Doesn't ordinal have the same problem as name?

Thats true, but I do suspect ordinal is rare enough to make the user select a different name.

I'll try an implementation with enumLabel

[smarter]

LGTM, but it'd be good to make a summary of all these enum changes and start a discussion in https://contributors.scala-lang.org/ to inform everyone about them.

[bishabosha]

rebased

[bishabosha]

rebased again

[julienrf]

Doesn't ordinal have the same problem as name? Maybe the real problem is that name is too common to be reserved by the language, and caseName or rawName (or enumName?) would be better.

I agree.

An alternative solution would be to synthesize a method def ordinal(enumValue: A): Int into the companion object of an enum A definition:

enum Foo:
  case Bar, Baz

Desugars to:

sealed trait Foo
object Foo:
  case object Bar extends Foo
  case object Baz extends Foo

  def ordinal(value: Foo): Int =
    value match:
      case Bar => 0
      case Baz => 1
end Foo

(the same could be done with enumLabel)

My second idea is to drop the support for enum cases that are not singleton values. (this also solves the problem of values not being always synthesized)

[bishabosha]

@julienrf so that ordinal method is already generated for the Mirror framework, and so that could definitely be enhanced for case label too, and so we're less likely to have method name collisions, but I am concerned about the linear lookup for large enums, but as its in the companion it could call a private non-colliding method on the enum class