Skip to content
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

Better handling of type parameters in constructor pattern #15356

Merged
merged 1 commit into from Jun 14, 2022

Conversation

odersky
Copy link
Contributor

@odersky odersky commented Jun 1, 2022

In a constructor pattern C[T](x) with some type parameter(s), we have two choices.

  1. Interpret it as C[T].unapply(selector)
  2. Interpret it as C.unapply[T](selector).

So far we always picked the first choice, which means that usually it will fail with a
message such as "C does not take type parameters".

In this PR, we pick the second choice if it can be typechecked without errors and
fall back to the first choice otherwise.

In a constructor pattern `C[T](x)` with some type parameter(s), we have two choices.

 1. Interpret it as `C[T].unapply(selector)`
 2. Interpret it as `C.unapply[T](selector)`.

So far we always picked the first choice, which means that usually it will fail with a
message such as "`C` does not take type parameters".

In this PR, we pick the second choice if it can be typechecked without errors and
fall back to the first choice otherwise.
@odersky
Copy link
Contributor Author

odersky commented Jun 6, 2022

test performance please

@dottybot
Copy link
Member

dottybot commented Jun 6, 2022

performance test scheduled: 1 job(s) in queue, 0 running.

@dottybot
Copy link
Member

dottybot commented Jun 6, 2022

Performance test finished successfully:

Visit https://dotty-bench.epfl.ch/15356/ to see the changes.

Benchmarks is based on merging with main (13ce496)

@odersky odersky requested a review from Kordyjan June 12, 2022 15:54
@odersky odersky added this to the 3.2.0-RC1 milestone Jun 13, 2022
@odersky
Copy link
Contributor Author

odersky commented Jun 13, 2022

Since this is a source breaking change, it would be good to ship it in 3.2.0.

Copy link
Contributor

@Kordyjan Kordyjan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@Kordyjan Kordyjan merged commit e9fbfd1 into scala:main Jun 14, 2022
@Kordyjan Kordyjan deleted the add-unapply-tparams branch June 14, 2022 06:40
odersky added a commit to dotty-staging/dotty that referenced this pull request Jul 13, 2022
scala#6551 introduced an exception where type tests of parameterized case classes were not flagged
as "type test cannot be checked at runtime". The idea was that the parameters would be inferred
by GADT reasoning and would therefore be correct.

But with scala#15356 we now also allow explicit type arguments in extractors. If these are given
we cannot guarantee that a type test for a case class in an unapply will always succeed.
So we need an unchecked warning.
@Kordyjan Kordyjan modified the milestones: 3.2.0-RC1, 3.2.0 Aug 1, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants