Unexpected widening of hard union of enum val cases to the enum class.

[markehammons]

Was: Match type reduction fails in suspicious way when enumerations are involved

Compiler version

3.4.0, 3.3.2

Minimized code

https://scastie.scala-lang.org/0x9CDEHuQlG6P5ABf9899g

enum A:
  case B
  case C
  case D

object A: 
  type B = B.type
  type C = C.type 
  type D = D.type

given A = A.B 

type Matcher[T] = T match 
  case A.C.type | A.D.type => Int
  case A.B.type => Float 


def fn[U <: A](using U)(value: Matcher[U]): Matcher[U] = value 


val x = summon[A] match 
  case given (A.C | A.D) => fn(5)
  case given A.B => fn(5f)

val y = summon[A] match 
  case given (A.C.type | A.D.type) => fn(5) //compiler error about cannot prove disjoint
  case given A.B.type => fn(5f) //compiler error about cannot prove disjoint

Output

trying to reduce Playground.Matcher[Playground.A]
failed since selector Playground.A
does not match case (Playground.A.C : Playground.A) | (Playground.A.D : Playground.A) => Int
and cannot be shown to be disjoint from it either.
Therefore, reduction cannot advance to the remaining case

Expectation

This should be fine, since A, B, C, and D are all sealed. The union type isn't the problem either because removing it still has the bottom two cases giving compile time errors (and of course the first case on x as well).

[markehammons]

I just retried this with sealed traits and case objects, and there are no compilation errors: https://scastie.scala-lang.org/mid01q9kSBiF5ZDKXjIwjg

sealed trait A 
object A: 
  case object B extends A
  case object C extends A
  case object D extends A
    
  type B = B.type
  type C = C.type 
  type D = D.type

given A = A.B 

type Matcher[T] = T match 
  case A.C.type | A.D.type => Int
  case A.B.type => Float 


def fn[U <: A](using U)(value: Matcher[U]): Matcher[U] = value 


val x = summon[A] match 
  case given (A.C | A.D) => fn(5)
  case given A.B => fn(5f)

val y = summon[A] match 
  case given (A.C.type | A.D.type) => fn(5)
  case given A.B.type => fn(5f)

[sjrd]

Please provide a reproduction that does not mix givens and usings at the same time. Right now it's hard to tell what gets inferred where.

The error itself seems completely reasonable to me: A (the enum class itself) is clearly not disjoint from its individual cases.

[markehammons]

First off, if the error is reasonable, then x should have compiler errors for it's cases, but doesn't.

Secondly, I'm passing in either the singleton types of the enum members or unions of those singleton types, never A.

[markehammons]

Please provide a reproduction that does not mix givens and usings at the same time. Right now it's hard to tell what gets inferred where.

The error itself seems completely reasonable to me: A (the enum class itself) is clearly not disjoint from its individual cases.

Here is a second example that doesn't use givens at all. The definition of x still compiles fine, while y has the disjoint error: https://scastie.scala-lang.org/R9iBC9YaQnmyvm5inNeb5Q

enum A:
  case B
  case C
  case D

object A: 
  type B = B.type
  type C = C.type 
  type D = D.type

type Matcher[T] = T match 
  case A.C.type | A.D.type => Int
  case A.B.type => Float 


val a: A.C | A.D = A.C

val b: A.C.type | A.D.type = A.C

def fn[U <: A](u: U)(value: Matcher[U]): Matcher[U] = value 


val x = fn(a)(5)
val y = fn(b)(5)

I'll note again that if the error on y is reasonable, there's still a bug because there's no error on x, and the only difference between the two is the usage of type aliases.

I'll also notice that discarding an enum for sealed traits/case objects in this second example has no compiler errors whatsoever, so it seems like the disjoint error on the y in the eum example is actually a bug: https://scastie.scala-lang.org/K0M8z3QzSBixflikBccD7Q

sealed trait A 
object A: 
  case object B extends A
  case object C extends A
  case object D extends A
    
  type B = B.type
  type C = C.type 
  type D = D.type

type Matcher[T] = T match 
  case A.C.type | A.D.type => Int
  case A.B.type => Float 

val a: A.C | A.D = A.C 

val b: A.C.type | A.D.type = A.D

def fn[U <: A](u: U)(value: Matcher[U]): Matcher[U] = value 


val x = fn(a)(5)
val y = fn(a)(5)

[dwijnand]

In the enum A + case C example, A.C is just a val instantiation of A, so it doesn't have a class identity like it does in the sealed trait A + case object C example. That matters for match reduction and disjointness, because it's just a singleton to the val and widens to A.

But that's when you make a type reference to the term val via A.C.type. When, instead, you make the type reference A.C, now you're referring to the type alias. It widens to the val singleton type, but it looks like it maintains its disjointness as such.

Not to passing judgement on what is or isn't a bug, just noting my knowledge. And often it's not possible to change these types of details too 🙁

[markehammons]

In the enum A + case C example, A.C is just a val instantiation of A, so it doesn't have a class identity like it does in the sealed trait A + case object C example. That matters for match reduction and disjointness, because it's just a singleton to the val and widens to A.

But that's when you make a type reference to the term val via A.C.type. When, instead, you make the type reference A.C, now you're referring to the type alias. It widens to the val singleton type, but it looks like it maintains its disjointness as such.

Not to passing judgement on what is or isn't a bug, just noting my knowledge. And often it's not possible to change these types of details too 🙁

What confuses me is how the val b gets widened to A. I very specifically define a union of singleton types for b, and this is recognized by the compiler by the fact that b cannot be instantiated with the value A.B. So the rules of the union of singletons is preserved at the definition of b, only two values can be used to instantiate it.

I'll note that this widening does not happen either in the case that I specify a new value z:

val z: Matcher[A.C.type | A.D.type] = 5

The match type reduces just fine for z, making it clear that its type is Int.

It seems like the widening happens from inference, as the following code also compiles just fine:

val zz = fn[A.C.type | A.D.type](b)(5)

[sjrd]

It seems like the widening happens from inference, as the following code also compiles just fine:

val zz = fn[A.C.type | A.D.type](b)(5)

Ah yes, then it's indeed inference. There's not much the match type can do if the call is inferred to be fn[A](b)(5) in the first place.

[dwijnand]

When infering the constraints on the type argument, it will pick up the separate components of the union in steps. But there is code to preserve that the original is a "hard" union, defined by the user (you). But I've seen it miss in the past. So I'll have a look at whether it can be captured in this case.

[markehammons]

I've reduced this further:
enum vs case object

enum A:
  case B
  case C
  case D

object A: 
  type B = B.type
  type C = C.type 
  type D = D.type

val a: A.C = A.C

val b: A.C.type = A.C

def fn[U](u: U): U = u 


val x = fn(a)
val y = fn(b)


def fn2(value: A.C.type): Unit = ()

//these lines don't compile
val xx = fn2(x)
val yy = fn2(y)

It seems that when it comes to members of an enum, inference very aggressively widens them even when it's not at all necessary to and in cases where other types would not. x and y above are inferred to A despite fn being the identity method. The case object setup does not have this situation at all, with fn inferring A.C.type properly.