Pattern-bound types with bad bounds lead to unsoundness

trait Foo[X >: Any <: Nothing]

@main def Test = (None: Option[Foo[?]]) match {
  case _: Option[Foo[t]] =>
    val unsound: Nothing = (5 : Any) : t
    (unsound : Unit => Unit).apply(())
}

The problem seems to be that pattern matching lets us name a type argument which does not correspond to a type member with known good bounds. In DOT, we would not be able to refer to t, so the issue would not show up.

Fixes we have thought of so far:

1. Disallowing classes with bad bounds on type parameters
2. Disallowing pat-mat from naming types with bad bounds / only letting pat-mat name types with bounds that are known to be good
3. Disallowing pat-mat from naming type arguments which are not top-level

See also the discussion in https://github.com/lampepfl/dotty/pull/15571 and related PR https://github.com/lampepfl/dotty/pull/15577.

[smarter]

In fact, I think ideally the compiler should define the pattern-bound symbol t to be an alias of x.A instead of an abstract type with some specific bounds, that way we don’t have to special-case them in the checking logic.

[odersky]

Note that the problem is more general than pattern bound types. For every pattern bound type t with bad bounds L, R, I can also simply write a local type definition

type t >: L <: R

with the same effect. In DOT we can’t do either since every type has to be a member of an object. So in DOT I’d have to write

val p = {
  type t >: L <: R
}

and then use p.t instead of t. But the definition of p would be rejected since t has bad bounds. It seems most in the spirit of DOT then to also reject the definition of t with bad bounds at the top-level. And likewise for pattern-bound types.