Fix #7554: Add TypeTest for sound pattern type test

[nicolasstucki]

Comparison with other kinds of type representations https://gist.github.com/nicolasstucki/ae3eaae553f594066bf9ad0e817f9a63

[odersky]

I strongly maintain that we should use ClassTag for this and not TypeTest. Let's fix/generalize broken abstractions instead of inventing new ones. That's the only way to keep complexity down.

[sjrd]

And I strongly maintain that ClassTags are not broken, and that it was type tests bolted on them that were broken since the beginning. Let's not fix what ain't broken, and let's put in two unrelated interfaces the two completely unrelated capabilities, namely that of creating Array[A]s and that of testing x.isInstanceOf[A]. Maintaining unrelated responsibilities in different interfaces is the only way to keep complexity down.

As @sjrd stated the issue is not that that ClassTags are broken but only the type test functionality that was added. This redefines the type tests functionality in a separate TypeTest class that has more a generalized API and stricter contract that fixes the shortcoming mentioned in #7554 and https://infoscience.epfl.ch/record/261291?ln=en .

[nicolasstucki]

We still need this to make the tasty.Reflection interface sound.

[dwijnand]

Is there a legal open-access version of https://infoscience.epfl.ch/record/261291?

[nicolasstucki]

It looks like the paper can be freely downloaded from https://dl.acm.org/doi/10.1145/3241653.3241658

[odersky]

I am still deeply opposed to introduce yet another form of type tag. We have too many of those already! So, I am sorry, that's a no go. At least not until we have tried out and tested all the alternatives.

Let's try to make a subtype of ClassTag that tests for prefixes. If that has a chance of working, it's much preferable to any alternative. I know some of you disagree on this, but I'll put my foot down on this one.

[nicolasstucki]

In #8993 I found that providing ClassTags were the type test is sound can lead unsoundess when using those ClassTags in arrays.

[nicolasstucki]

Also see https://gist.github.com/nicolasstucki/ae3eaae553f594066bf9ad0e817f9a63

[milessabin]

What do people think about this alternative?

If it preserves (or improves the precision of) the semantics of shapeless's Typeable then 👍

shapeless has a gadget for using its Typeable in pattern matches, but its ergonomics on Scala 2 aren't great,

@Test
def testTypeCase: Unit = {
  import HList.ListCompat._

  def typeCase[T: Typeable](t: Any): Option[T] = {
    val T = TypeCase[T]
    val `List[T]` = TypeCase[List[T]]
    val `(String, T)` = TypeCase[(String, T)]
    val `List[(String, T)]` = TypeCase[List[(String, T)]]

    t match {
      case T(t) => Some(t)
      case `List[T]`(lt) => lt.headOption
      case `(String, T)`(s, t) => typed[String](s) ; Some(t)
      case `List[(String, T)]`((s, t) :: _) => typed[String](s); Some(t)
      case `List[(String, T)]`(lst) => assertTrue(lst.isEmpty) ; None
      case _ => None
    }
  }

  assertEquals(Some(23), typeCase[Int](23: Any))
  assertEquals(None, typeCase[String](23: Any))
  assertEquals(Some(23), typeCase[Int](List(23): Any))
  assertEquals(None, typeCase[String](List(23): Any))
  assertEquals(Some(23), typeCase[Int](("foo", 23): Any))
  assertEquals(None, typeCase[String](("foo", 23): Any))
  assertEquals(Some(23), typeCase[Int](List(("foo", 23)): Any))
  assertEquals(None, typeCase[String](List(("foo", 23)): Any))
}

It would be great if Scala 3 supported pattern syntax similar to the above without having to resort to backtick puns.

[nicolasstucki]

Rebased

[odersky]

Code looks good, it's just the doc page that needs some fixes.