Named tuple selector type in match means no exhaustivity

[som-snytt]

Compiler version

3.7.1-RC1-bin-SNAPSHOT-nonbootstrapped-git-f0c050e

Minimized code

scala> type Person = (name: String, age: Int)
// defined alias type Person = (name : String, age : Int)

scala> val u = ("fred", 65)
val u: (String, Int) = (fred,65)

scala> val t = ("fred", 64)
val t: (String, Int) = (fred,64)

scala> val Fred: Person = t
val Fred: Person = (fred,64)

scala> ("bob", 24) match { case `u` => 0 }
1 warning found
-- [E029] Pattern Match Exhaustivity Warning: ----------------------------------
1 |("bob", 24) match { case `u` => 0 }
  |^^^^^^^^^^^
  |match may not be exhaustive.
  |
  |It would fail on pattern case: (_, _)
  |
  | longer explanation available when compiling with `-explain`
scala.MatchError: (bob,24) (of class scala.Tuple2)
  ... 33 elided

scala> Fred match { case `u` => 0 }
scala.MatchError: (fred,64) (of class scala.Tuple2)
  ... 33 elided

scala> (("bob", 24): Person) match { case (x, 48) => 0 }
scala.MatchError: (bob,24) (of class scala.Tuple2)
  ... 33 elided

scala>

Expectation

This seems like a natural thing to do, so I expect the warning.

[som-snytt]

Now I forgot what I was doing... I was fixing -Wunused:patvars on Scala 2 (to be more like Scala 3), but named constructor patterns makes heuristics for patvars less beneficial (as anticipated on Scala 2, when named pattern elements first surfaced).

case C(x, y, z) => y // don't warn about canonical names (patvar named after the case class element)
case C(_, y, _) => y // annoying
case C(x@_, y, z@_) => y // boilerplated workaround on scala 2 (for non-canonical names)
case C(y = v) => // we can have nice things!

but what about

val C(y = v)
class D(c: C) { val C(j = y) = c: @unchecked } // also noice!

This bolsters the case for warning under -Wunused:patvars and not privates (which is for non-patvar-defs). The bizarre or beautiful syntax is even more clearly a patvar. (The upshot is that all the warnings should be turned on together; and maybe in future the language will support requiring named elements to be "used".)