-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Refine type inference rules for IFTs #3448
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
odersky
added a commit
to dotty-staging/dotty
that referenced
this issue
Nov 9, 2017
We now treat a type as an implicit function type also if it is a type variable that has an IFT as upper bound in the current constraint. This means we now create implicit closures if the expected type is such a type.
odersky
added a commit
to dotty-staging/dotty
that referenced
this issue
Nov 9, 2017
We now treat a type as an implicit function type also if it is a type variable that has an IFT as upper bound in the current constraint. This means we now create implicit closures if the expected type is such a type.
This problem was discovered while playing with IFts with Adam Warski at Devoxx. |
odersky
added a commit
that referenced
this issue
Nov 17, 2017
Fix #3448 Improve Type inference for IFTs
nicolasstucki
pushed a commit
to dotty-staging/dotty
that referenced
this issue
Nov 17, 2017
We now treat a type as an implicit function type also if it is a type variable that has an IFT as upper bound in the current constraint. This means we now create implicit closures if the expected type is such a type.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The following does not work currently:
We get a "no implicit found for A" on the last occurrence of
x
. The reason is that at the pointx
is typed the expected type is still a type variable with an IFT as upper bound in the constraint. These are not recognized as IFTs, and consequentlyx
is not expanded to a closure.I think this is something that can be fixed by refining the rules.
We should treat as an implicit function types not only instances of
ImplicitFunctionN
and their aliases but also type variables that have an IFT as their upper bound.The text was updated successfully, but these errors were encountered: