Use union of cases as default bound of match types

[OlivierBlanvillain]

Fix lampepfl/dotty-feature-requests#90

This PR implements what @LPTK suggested at the end of the issue, which is to use the union of cases as the bound of match types when no bounds are provided.

Unfortunatly the snippet from the linked issue still doesn't compile, but I think the remaining issue might be unrelated to match type (see #8084).

[LPTK]

Wouldn't this cause problems when body contains references to type variables extracted from a type pattern?
As in: ... match { case List[t] => t }

[OlivierBlanvillain]

This change doesn't work well with nested matches. For instance, lets have a look at type Elem from Tuple.scala:

type Elem[X <: Tuple, N <: Int] <: Any = X match {
  case x *: xs =>
    N match {
      case 0 => x
      case S[n1] => Elem[xs, n1]
    }
}

With this change, the inner type N match { ... } gets Any | Elem[? <: Tuple, Int] as its bounds, which create cyclic references at use site.

The main issue here is that we don't have syntax to specify bounds outside of type definition, meaning the above would have to be rewritten as:

type Elem[X <: Tuple, N <: Int] <: Any = X match {
  case x *: xs => Elem0[N, x, xs]
}
type Elem0[N <: Int, X <: Any, XS <: Tuple] <: Any match {
  case 0 => X
  case S[n1] => Elem[XS, n1]
}

Assuming we had better syntax for that, there is some more work needed to make this change viable: the compiler needs the detect cycles and report an error similar to what we have for recursive functions ("recursive match type need explicit bounds"). I think that might bit tricky to implement, given that the cyclic references are only triggered at use site (during subtyping), we would have some additional mechanism when compiling a match type to detect these and error out accordingly.

[LPTK]

I see, thanks for looking into it @OlivierBlanvillain!

It seems to me that the appropriate thing to do here would be type avoidance of the types being defined while computing the match type bounds, using the bounds actually specified by the user. So instead of Any | Elem[? <: Tuple, Int] we'd get Any | Any in this example.

I don't know whether that could be done easily, though.