-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Difference between case _
and case Any
in match types
#9171
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Labels
Comments
Furthermore, the distinction between the two also affects unification with match expression, for instance the following doesn't compile on master (but does with case object Test1 {
type M[X] = X match { case String => Int case Any => String }
def m[X](x: X): M[X] = x match { case _: String => 1 case _ => "s" }
} |
OlivierBlanvillain
added a commit
to dotty-staging/dotty
that referenced
this issue
Jun 12, 2020
`case _ =>` use to be typed as a `HKTypeLambda`, despite not binding anything. As a result, result of match type reduction going through `case _` would get further reduce that their `case Any` counterpart. This commit eliminates this distinction with the following changes: - Eliminate this distinction in typing (type `case _ =>` *as* `case Any =>`) - Simplify the body of match types in non-binding cases - Change the match type/expression unification to treat the `case _ =>` in a pattern like `case _: Any =>` Unfortunately this change introduces a regression in `matchtype-loop.scala` where the loop suddenly turns into an infinite loop that doesn't stack overflow. I don't see any other way to nicely fail than to introduce a new fuel-like counter to keep track of match type reductions.
OlivierBlanvillain
added a commit
to dotty-staging/dotty
that referenced
this issue
Apr 23, 2021
`case _ =>` use to be typed as a `HKTypeLambda`, despite not binding anything. As a result, result of match type reduction going through `case _` would get further reduce that their `case Any` counterpart. This commit eliminates this distinction with the following changes: - Eliminate this distinction in typing (type `case _ =>` *as* `case Any =>`) - Simplify the body of match types in non-binding cases - Change the match type/expression unification to treat the `case _ =>` in a pattern like `case _: Any =>` Unfortunately this change introduces a regression in `matchtype-loop.scala` where the loop suddenly turns into an infinite loop that doesn't stack overflow. I don't see any other way to nicely fail than to introduce a new fuel-like counter to keep track of match type reductions.
OlivierBlanvillain
added a commit
to dotty-staging/dotty
that referenced
this issue
Apr 28, 2021
OlivierBlanvillain
added a commit
to dotty-staging/dotty
that referenced
this issue
Apr 28, 2021
OlivierBlanvillain
added a commit
to dotty-staging/dotty
that referenced
this issue
May 12, 2021
OlivierBlanvillain
added a commit
to dotty-staging/dotty
that referenced
this issue
May 18, 2021
OlivierBlanvillain
added a commit
to dotty-staging/dotty
that referenced
this issue
May 27, 2021
OlivierBlanvillain
added a commit
to dotty-staging/dotty
that referenced
this issue
Jun 9, 2021
OlivierBlanvillain
added a commit
to dotty-staging/dotty
that referenced
this issue
Jul 29, 2021
OlivierBlanvillain
added a commit
to dotty-staging/dotty
that referenced
this issue
Sep 8, 2021
OlivierBlanvillain
added a commit
to dotty-staging/dotty
that referenced
this issue
Sep 22, 2021
OlivierBlanvillain
added a commit
to dotty-staging/dotty
that referenced
this issue
Sep 22, 2021
olsdavis
pushed a commit
to olsdavis/dotty
that referenced
this issue
Apr 4, 2022
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
While playing with
i8449.scala
, I noticed that there is a difference betweencase _
andcase Any
in match types:(This test compiles fine with
case _
inatead ofcase Any
).The text was updated successfully, but these errors were encountered: