Unexpected type widening after `copy`

[felix-hedenstrom]

Compiler version

3.3.7, 3.7.4, 3.8.3

Minimized code

//> using scala 3.8.3

enum Animal:
  case Cat(meow: String)
  
def meow(cat: Animal.Cat): String = cat.meow
  
@main
def main: Unit =  {
  val cat: Animal.Cat = Animal.Cat("meow")

  val catWithBetterMeow = cat.copy(meow = "_€%")

  println(meow(catWithBetterMeow))
}

Output

[error] ./copy-issue.scala:14:16
[error] Found:    (catWithBetterMeow : Animal)
[error] Required: Animal.Cat
[error]   println(meow(catWithBetterMeow))
[error]                ^^^^^^^^^^^^^^^^^

Expectation

For the type of catWithBetterMeow to be inferred as Animal.Cat and that the program compiled.

We can explicitly annotate it with val catWithBetterMeow: Animal.Cat in which case it compiles fine.

[felix-hedenstrom]

This unexpected behavior was found while trying to reproduce an actual regression. We finally managed to reproduce it without external libraries here #25742

The other one is a clear regression but this issue is more of unexpected behavior.

[sjrd]

Looks like another casualty of typing enum cases as their enum type, rather than the individual case types. 🤷‍♂️

[SolalPirelli]

We have a test that expects this behavior:
https://github.com/scala/scala3/blob/main/tests/pos/enum-widen.scala#L9-L14

#25742 is technically a regression but it really aligns with the expected behavior :/

Agreed with @sjrd , this is a casualty of something that also has benefits.

[felix-hedenstrom]

Sorry, I don't see how the test expects this behavior. Where does the widening happen?

Could you help me understand what benefits there are to this?

[SolalPirelli]

In that test, if we don't widen xc to Option despite it being a copy of y which is more precisely a Some, then line 14 fails to compile because we can't assign None to a Some (but we can if it's widened to Option).

This test is a little weird because in order to test this behavior it defines its own Option as an enum instead of using the standard library's, but it provides a good example of why widening can be beneficial, even though in general it's controversial because we effectively have to guess what the user wants and hope our guess is correct.

For instance, right now if you write val x = ListBuffer(Some(42)), you then cannot write x += None, because we don't widen since the stdlib's Option is not an enum, so x is of type ListBuffer[Some[Int]] which may or may not be what the user intended.

This is also true of, e.g., singleton types. You can write val y = ListBuffer(1) and then y += 2 because we widened 1 to Int in the type of y, since we assume the user doesn't intend to create a ListBuffer[1], unless they explicitly annotate the val as such.

[felix-hedenstrom]

If there was no automatic widening here I think I would blame ListBuffer being invariant more than I would blame the compiler for not automatically widening.

I expect enums to work similarly to their sealed trait counterparts in most cases so I was very surprised by this.

[felix-hedenstrom]

Is there an intention to rewrite Option to use enum at some point as well? Doing so would probably be breaking if anyone has methods that expect Some[Int] types to be preserved.

[som-snytt]

The weird example is the paradigm in the reference.

https://www.scala-lang.org/files/archive/api/current/docs/enums/adts.html

where it says, "This is a subtle difference with respect to normal case classes."

I didn't remember that there is an exemption for new, but now I am prepared for the quiz.