Skip to content

Type evaluation for 'Tuple.apply()' shows surprising behavior #11977

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

Closed
MRandl opened this issue Apr 3, 2021 · 2 comments · Fixed by #11980
Closed

Type evaluation for 'Tuple.apply()' shows surprising behavior #11977

MRandl opened this issue Apr 3, 2021 · 2 comments · Fixed by #11980
Labels
itype:bug regression This worked in a previous version but doesn't anymore
Milestone

Comments

@MRandl
Copy link

MRandl commented Apr 3, 2021

Compiler version

tested on rc1 and rc2, linux and windows. Also replicates on Scastie.

Minimized code

def add(a : (Int, String), b : (Int, String)) : (Int, String) = (a(0) + b(0), a(1) + b(1))

Output

(a(0) + b(0), ...) <- Found Long, required Int

Expectation

You would expect this code to compile correctly and accept the fact that a(0) + b(0) is an Int and not a Long

Workaround

Replacing a(0) + b(0) by a._1 + b._1 makes it work correctly

Anton Sviridov on Gitter greatly simplified my original problematic code

@MRandl
Copy link
Author

MRandl commented Apr 3, 2021

Similar bug by Anton :

def add(s : (Long, String), t : (Long, String)) : (Long, String) = (s(0) + t(0), s(1) + t(1))

now expects a Float where we want a Long

@MRandl MRandl changed the title Type inference for tuples shows surprising behavior Type evaluation for 'Tuple.apply()' shows surprising behavior Apr 3, 2021
@griggt
Copy link
Contributor

griggt commented Apr 3, 2021

Seems to be a regression in #9984. Does not occur with -Yforce-inline-while-typing

@griggt griggt added the regression This worked in a previous version but doesn't anymore label Apr 3, 2021
odersky added a commit to dotty-staging/dotty that referenced this issue Apr 3, 2021
Fixes scala#11977

Previously the match types were more often fully defined because inlining at Typer
caused more situations where type variables were instantiated. Now that inlining
is done later, we need to compensate. I believe it's a good idea anyway since it
means we can reduce more match types.
michelou pushed a commit to michelou/scala3 that referenced this issue Apr 9, 2021
Fixes scala#11977

Previously the match types were more often fully defined because inlining at Typer
caused more situations where type variables were instantiated. Now that inlining
is done later, we need to compensate. I believe it's a good idea anyway since it
means we can reduce more match types.
odersky added a commit to dotty-staging/dotty that referenced this issue Apr 12, 2021
Fixes scala#11977

Previously the match types were more often fully defined because inlining at Typer
caused more situations where type variables were instantiated. Now that inlining
is done later, we need to compensate. I believe it's a good idea anyway since it
means we can reduce more match types.
michelou pushed a commit to michelou/scala3 that referenced this issue Apr 14, 2021
Fixes scala#11977

Previously the match types were more often fully defined because inlining at Typer
caused more situations where type variables were instantiated. Now that inlining
is done later, we need to compensate. I believe it's a good idea anyway since it
means we can reduce more match types.
@Kordyjan Kordyjan added this to the 3.0.1 milestone Aug 2, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
itype:bug regression This worked in a previous version but doesn't anymore
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants