Explicit type specification in `match` worsens type checks about scala3 HOT 1 OPEN

I don't nessaserilly agree with the assessment that this is removing an additional check - its simply erroring before you get to the check that you have in both.

If we break down the logic a bit more, in the first example this is trying to break down example into a tuple, and then attempting to pattern match inside of it.

In the second example, a and b do not exist unless you have already successfully run extractors on a Tuple2[Int, Int] - which is going to fail.

Imagine a case where the inner extractor was not a simple type check, but passing through to some custom unapply method, which accepted only positive Ints, and ascii strings. In this hypothetical, the user in the first case would be asking "Do I have two fields which are either posative ints or ascii strings" and in the second is asking "Do I have exactly two posative ints".

We could also consider examples which were more complex than a simple tuple. For example class Foo[T](foo: Int | T). In this case an extractor of Foo[Int](a: int) is clearly stronger than Foo(a:Int) - and it would be up to the implementation of Foo.unapply to determine how this further refinement was handled. In the case of case classes (and thus tuples) - unapply promises to preserve known types - and thus has to fail when the types is wrong.

If we wanted to make this work it would be opening up a whole heap of things in constructs like val Tuple2[Int,Int](a, b) = (???,???) with a and b not getting the fully validated type.

from scala3.