Fix #12260: Add underscore to match type syntax

[OlivierBlanvillain]

Also subsumes #9172 by fixing #9171.

[odersky]

simplify is very costly. So we do it once when we generate types. Why is it needed in type constant folding? We should try to avoid it there, or some code that constant folds a lot might blow up in complexity.

[OlivierBlanvillain]

I opened #12278 to discuss simplify separately, it's orthogonal to this PR.

[odersky]

I think those should be _ => String since that was what's written.

[OlivierBlanvillain]

I updated the PR with another attempt, this time parsing case _ as Ident(_) and typing the corresponding tree as Any. I think it's overall much cleaner but we still lose the distinction between case _ and case Any in the error message...

[SethTisue]

What's the status of case ??

If I understand correctly, there's three ways to write the same thing: case ?, case _, and case Any, and they are all intended to be synonymous? Is one of them considered preferred style?

In term-level matches, under -source:future I'm expected to write e.g. case xs: List[?] rather than case _: List[_], so this sets an expectation that the way to write "any type, I don't care" is ?, not _. If so, why support case _?

(I don't have any firm opinions about this, I'm just asking questions...)

[OlivierBlanvillain]

If I understand correctly, there's three ways to write the same thing: case ?, case _, and case Any, and they are all intended to be synonymous?

Yes, they are 3 equivalant ways to write catch-all patterns for match types. The situation is actually symetrical between term and type level:

def foo(x) = x match
  case _ =>
  case _: Any =>
  case _: ? => // Unlike scalac which complains with
               // "error: unbound wildcard type",
               // Dotty is perfectly fine with this...

type Foo[X] = X match
  case _ =>
  case Any =>
  case ? =>

Is one of them considered preferred style?

I like case _ => for the symmetry, but it's just my personal preference :)

[som-snytt]

Previous missed opportunity was to accept case if expr => and perhaps case =>. Now that seems less weird.

I sense a pun on "Casey at the Bat" coming on. "There is no joy in Matchville."

[dwijnand]

Yes, they are 3 equivalant ways to write catch-all patterns for match types. The situation is actually symetrical between term and type level:

Those aren't equivalent though: in the match expression it's switching from terms to types, while in match types it's types only. So I feel like we either embrace the symmetry with match expressions and make case _ => the "symbolic" catch all, or we embrace that ? as the symbol for 🤷🏼 and deprecate case _ =>. 3 options seems unnecessary to me.

[OlivierBlanvillain]

The community build fails without the case ? => (it's used in scodecs). I propose to move that discussion to a separate issue.

[OlivierBlanvillain]

rebased

[bishabosha]

New issue that would be fixed by this: #13855