Skip to content

Fix #5826: specialize union types to avoid constraint cut #5858

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 2 commits into from
Feb 7, 2019

Conversation

liufengyun
Copy link
Contributor

Fix #5826: specialize union types to avoid constraint cut

Copy link
Contributor

@Blaisorblade Blaisorblade left a comment

Choose a reason for hiding this comment

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

This looks reasonable to me, tho I'm not sure about the explanation... It can go in anyway maybe, but I'd at least add the extra tests? Maybe @AleksanderBG can say more...

@@ -0,0 +1,20 @@
class Foo {
def test[A]: List[Int] | A => Int = {
case ls: List[Int] => ls.head // error
Copy link
Contributor

Choose a reason for hiding this comment

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

We should also make sure to test that GADT matching doesn't infer Int:

case ls: List[_] => ls.head       // error

and that List[_] is otherwise still allowed:

case ls: List[_] => ls.length // no error here!

X.widen match {
case OrType(tp1, tp2) =>
// This case is required to retrofit type inference,
// which cut constraints in the following two cases:
Copy link
Contributor

Choose a reason for hiding this comment

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

I'm familiar with TypeComparer#either but I'm not sure I get what you are saying...

This case is required to match type inference, which simplifies constraints in the following two cases:

But if that's the reason, what about T1 & T2 <:< T3? Do we need to handle that somehow?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

T1 & T2 <:< T3 is handled in the top-level match on P

@Blaisorblade Blaisorblade merged commit 71dbcab into scala:master Feb 7, 2019
@Blaisorblade Blaisorblade deleted the fix-5826 branch February 7, 2019 03:58
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.

2 participants