Match types don't reduce on opaque types

Compiler version

nightly: 3.0.1-RC1-bin-20210531-fa36577-NIGHTLY

Minimized code

object test {
  object opaques {
    opaque type @@[+S <: String & Singleton, +T] >: T = T
  }
  import opaques.*
  type FieldName[T] = T match {
    case @@[name, _] => name
    case _ => "other"
  }
  //neither of these compiles
  val a1: FieldName["a" @@ String] = "a" //doesn't  match the immediate case
  val a2: FieldName["a" @@ String] = "other" //doesn't go to other either
}

Expectation

a1 should compile

As far as I can tell, the above opaque type should never hit the rules for non-reducing. If the above opaque type is changed to the equivalent trait it behaves as expected

[LPTK]

The problem is that given any T, you have the subtyping relationship T <: @@[S, T], where S can be anything. So the first case should always match, no matter what.

There is nothing to force the compiler to actually make the effort and see if there is a better way of matching the argument. In other words, in @@[A, B] <: @@[x, y], x = Nothing; y = @@[a, b] and x = a; y = b are two equally good solutions.

In general, there may be many solutions, but what usually keeps match types kind of unambiguous is that they are not usually made to work on “imaginary” types like @@, which is obviously (because of the bound) not a “real, physical type” but just a type system trick.

[rcano]

Thank you for the explanation, I think I know see where my misconception is: Your explanation makes all the sense to me if we were discussing type inference, maybe it’s the imperativeness of the term “match” that made me think this works more like a function on types, or the paragraph I quoted from the docs, but I was expecting the compiler to use the input I’m giving to the match case to make the effort to infer a “better response”, compared to just inferring a generally valid solution.

This makes me think that the documentation about match types should be rewritten because it conveys the wrong message. In any case I’m closing this issue. Thanks a lot for the help.