-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Harmonize PolyType and TypeLambda #1560
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
Conversation
Needs to be rebased after the inline merge |
777c309
to
0653344
Compare
Rebased to master |
eb71034
to
c16cefb
Compare
In theory this commit paves the way to allow polymorphic types as value types. A test of some |
6b0e68f
to
d1cd209
Compare
2ab3e5c
to
bc786d7
Compare
Let them inherit the same traits and push as much functionality as possibly into the common superclass GenericType.
to account for the fact the GenericTypes are now TypeProxies.
Otherwise we can run into problems when checking imports for e.g. scala2Mode in later runs.
The refactored logic only applies to infos of denotations, not general types. The reactoring avoids special cases down the road then PolyTypes and MethodTypes can be used for terms as well as type(bounds).
If PolyTypes are to become value types we want to keep `=>` as the arrow for consistency. `->` should be reserved for PolyTypes that do not have side effects on instantiation.
bc786d7
to
9e74d72
Compare
Rebased after the union-type PR merge |
LGTM, I wonder if we can merge |
Yes, interesting question. PolyParam is a reference to a parameter, whereas LambdaParam is a surrogate for a symbol, i.e. a definition. So it's not obvious, but still worth thinking about it. |
Push as much as we can into common superclass GenericType. Review by @smarter.
Update: I managed to completely eliminate any distinction between PolyType and TypeLambda. They are the same type now, and GenericType as a supertype could also be eliminated.