Skip to content

Don't simplify |/& by taking lubs/glbs for explicitly declared types. #885

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
wants to merge 2 commits into from

Conversation

odersky
Copy link
Contributor

@odersky odersky commented Oct 29, 2015

A lub might return a different type (i.e. singleton types are widenened).
We should not do this if the type is given explicitly.

This is a more conservative version of #844. Review by @smarter.
@smarter can you push your tests on top of this PR? Thanks!

A lub might return a different type (i.e. singleton types are widenened).
We should not do this if the type is given explicitly.
@smarter
Copy link
Member

smarter commented Oct 30, 2015

/rebuild

@smarter
Copy link
Member

smarter commented Oct 30, 2015

val foo: a.type | b.type = a
val bar: a.type | b.type = foo

The type of the tree corresponding to foo in the right-hand side of bar is going to be adapted, and since the type is not written explicitly it will be simplified to Int, so we'll get a type mismatch.

@odersky
Copy link
Contributor Author

odersky commented Oct 30, 2015

I think all this is correct. But what can we do? Disallow unions of
singletons in types?

On Fri, Oct 30, 2015 at 10:05 AM, Guillaume Martres <
[email protected]> wrote:

val foo: a.type | b.type = aval bar: a.type | b.type = foo

The type of the tree corresponding to foo in the right-hand side of bar
is going to be adapted, and since the type is not written explicitly it
will be simplified to Int, so we'll get a type mismatch.


Reply to this email directly or view it on GitHub
#885 (comment).

Martin Odersky
EPFL

@smarter
Copy link
Member

smarter commented Oct 30, 2015

Well, #844 seems to work fine, do you see any cases where it might do something wrong?

@odersky
Copy link
Contributor Author

odersky commented Oct 30, 2015

The danger with #844 is that it produces too large types and will make
inference very slow or even cause it to blow up. Hard to test for it.

On Fri, Oct 30, 2015 at 10:15 AM, Guillaume Martres <
[email protected]> wrote:

Well, #844 #844 seems to work
fine, do you see any cases where it might do something wrong?


Reply to this email directly or view it on GitHub
#885 (comment).

Martin Odersky
EPFL

@odersky
Copy link
Contributor Author

odersky commented Oct 30, 2015

I now believe we are on the wrong track altogether. Messing with the meaning of lubs gets us into trouble. If we want lubs to widen singleton types we have to disallow union types consisting of singleton types. Everything else would be too operational.

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