Sealed traits behave different than sealed class for type match reduction

[jrudolph]

Compiler version

3.0.1

Minimized code

  sealed class R

  type X[T] = T match {
    case R        => String
    case (z => r) => Int
  }
  def x[T]: X[T] = ???
  
  def i(i0: Int): Unit = ???
  i(x[Int => String])

This match type fails with

[error] 30 |  i(x[Int => String])
[error]    |    ^^^^^^^^^^^^^^^^
[error]    |    Found:    X[Int => String]
[error]    |    Required: Int
[error]    |
[error]    |    Note: a match type could not be fully reduced:
[error]    |
[error]    |      trying to reduce  X[Int => String]
[error]    |      failed since selector  Int => String
[error]    |      does not match  case R => String
[error]    |      and cannot be shown to be disjoint from it either.
[error]    |      Therefore, reduction cannot advance to the remaining case
[error]    |
[error]    |        case z => r => Int

when the same example with

  sealed trait R

works?

Expectation

Both examples compile.

[dwijnand]

The difference is that sealed trait R is uninhabited because it's abstract, sealed, and has no subclasses. sealed class R, instead, is only inhabited by values of type R, which isn't provably disjoin from Function1, because Function1 isn't sealed. I.e. there could be values of type R & Function1[X, Y], which is where match type reduction stops.

[jrudolph]

How would you create a value of type R & Function1[X, Y] (in another file)?

[dwijnand]

You can't. But I don't think "probablyDisjoint" explores that, to keep it cheap. Perhaps getting it to do that is an acceptable cost.

[jrudolph]

Ah, makes sense then, thanks for the explanation, @dwijnand.