Skip to content

Fix #4774: Skip TypeVars and skip if level is equal #4775

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

Merged
merged 1 commit into from
Jul 8, 2018

Conversation

nicolasstucki
Copy link
Contributor

If we have ~t for t: Type[T] used at the same level it is an alias for T.
We disallow it if it is explicit because of PCP but if it is infered it is fine.

If we have ~t for `t: Type[T]` used at the same level it is an alias for T.
We disallow it if it is explicit because of PCP but if it is infered it is fine.
@odersky odersky merged commit 5dcf4b9 into scala:master Jul 8, 2018
@allanrenucci allanrenucci deleted the fix-#4774 branch July 8, 2018 10:22
@smarter
Copy link
Member

smarter commented Jul 8, 2018

We disallow it if it is explicit because of PCP but if it is infered it is fine.

I don't understand the context here but this seems very weird to me. If a type can be inferred it should also be something that the user can write by hand, this has always been the case in Scala so far and is much more user-friendly than the alternative.

@nicolasstucki
Copy link
Contributor Author

Oh, in this context it can be written by hand. The user can write loop(...) or loop[T](...). In the example, the former gets inferred to loop[~t](...) where ~t is an alias of T, which is fine, we can assume it is just a T. We disallow the ~t as it would not be syntactically PCP.

@Blaisorblade
Copy link
Contributor

@nicolasstucki As I mentioned earlier, I don't believe the PCP actually works until you can explain how it should apply to types without needing all these exceptions.

@nicolasstucki
Copy link
Contributor Author

This is just an implementation detail that I missed.

@smarter
Copy link
Member

smarter commented Jul 8, 2018

~t is an alias of T, which is fine, we can assume it is just a T

I see, that seems OK, but it might be problematic if the ~t leaks into error messages shown to the user

@smarter
Copy link
Member

smarter commented Jul 8, 2018

It could also leak when decompiling from Tasty, or in some other ways (e.g. if we add a mode to the IDE to desugar/type-infer an expression).

@nicolasstucki
Copy link
Contributor Author

Good point. Then the type should be dealiased and replaced.

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.

4 participants