This issue was picked for the Scala Issue Spree of tomorrow, Monday, February 24th. @SethTisue, @kyouko-taiga and @mbovel will be working on it. If you have any insight into the issue or guidance on how to fix it, please leave it here.

Minimized to:

object Matches:
  def unapply(y: Any)[T]: Option[Any] = None

def main =
  42 match
    case Matches(x) => println(x)

However, moving the type parameter makes is compile:

object Matches:
  def unapply[T](y: Any): Option[Any] = None

def main =
  42 match
    case Matches(x) => println(x)

Error case:

TypeApply(Apply(Select(Ident(Matches),unapply),List(Literal(Constant(null)))),List(TypeTree[TypeVar(TypeParamRef(T))]))

Happy case:

Apply(TypeApply(Select(Ident(Matches),unapply),List(TypeTree[TypeVar(TypeParamRef(T))])),List(Literal(Constant(null))))

@Sporarum do you think that should be accepted? 😄

The problem is that the Unapply node cannot store type arguments. In the case where we have object Foo { def unapply[T](x: Any): Option[Any] }, it's not problem because we can reduce the call to Any => Option[Any] by passing the type argument. But when the type argument is after as in object Foo { def unapply(x: Any)[T]: Option[Any] }, it's not clear what we should do.

Martin thinks that we should not support type parameters after parameter lists for unapply methods.

For me the question resides in:
How useful are path dependent usings in unapply methods ?

If they are not useful, there's no need to support this pattern

If they are useful (and have no good alternatives), then we should support this feature

Regardless, the compiler should not crash ^^"