Skip to content
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

Make singleton operations covariant #14452

Merged
merged 2 commits into from Feb 28, 2022

Conversation

mbovel
Copy link
Member

@mbovel mbovel commented Feb 11, 2022

Currently, this does not compile:

def mult(x: Int, y: Int): x.type * y.type = (x * y).asInstanceOf
val y: x.type * x.type * x.type = mult(mult(x, x), x)
|                                 ^^^^^^^^^^^^^^^^^^^
|Found:    (?1 : (Test.x : Int) * (Test.x : Int)) * (Test.x : Int)
|Required: (Test.x : Int) * (Test.x : Int) * (Test.x : Int)
because (x: X) * Y is not a subtype of X * Y.

because (x: X) * Y is not a subtype of X * Y.

Making the compiletime operation types covariant in their arguments would enable this.

@mbovel mbovel force-pushed the mb/compiletime-ops-covariant branch from c59038d to d913504 Compare February 11, 2022 14:18
@soronpo
Copy link
Contributor

soronpo commented Feb 11, 2022

The problem is that covariance and contravariance encourage the compiler to widen. I wonder if it has any unwanted side effect.

@mbovel
Copy link
Member Author

mbovel commented Feb 11, 2022

I think covariance allows the compiler to widen when it is actually useful. In my experiments with singleton ops, the impossibility to compare operations containing skolems or term references is a big blocker.

We definitely need a way to preserve precise types and I am experimenting with different possibilities (such as an exact or precise type modifier as you suggested), but that seems orthogonal to this covariance problem to me. What do you think?

@mbovel mbovel marked this pull request as ready for review February 11, 2022 15:56
@soronpo
Copy link
Contributor

soronpo commented Feb 11, 2022

I'll try this branch on my code-base to see if it has any unwanted effect. I'll reply when I'm done.

@MaximeKjaer
Copy link
Collaborator

This looks very reasonable to me. Seems intuitive that 1 + 2 should be a subtype of 1 + Int or Int + Int.

I don't feel comfortable marking the PR as approved myself, because I don't actively contribute to the repo, and I might not have the full picture. But I do otherwise approve of the change!

Unless we have a specific counter-example of how covariance might result in unexpected widenings and break things right now, then I think that as long as tests pass, we can merge this.

One thing you could try to do to make sure that this works is to compile the community build, or maybe just a few projects that make heavy use of singleton ops (e.g. tf-dotty -- you can ping me if you need any help with this).

Copy link
Contributor

@soronpo soronpo left a comment

Choose a reason for hiding this comment

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

I checked this branch effect on my library, and nothing "bad" happened.
The implementation LGTM.

@mbovel
Copy link
Member Author

mbovel commented Feb 11, 2022

One thing you could try to do to make sure that this works is to compile the community build, or maybe just a few projects that make heavy use of singleton ops (e.g. tf-dotty -- you can ping me if you need any help with this).

tf-dotty is included in the CI tests as part of community_build_c 😄 onnx-scala is included as part of community_build_c. It uses io.kjaer.compiletime like tf-dotty so it should be a good test already. I'll test with tf-dotty as well.

@som-snytt
Copy link
Contributor

The appropriate approval pun would be +1!

@mbovel
Copy link
Member Author

mbovel commented Feb 14, 2022

I'll test with tf-dotty as well.

@MaximeKjaer IndicesSuite and ShapeSuite pass successfully with the changes in this PR ✔️

@@ -42,7 +42,7 @@ object any:
* @syntax markdown
*/
@experimental
type IsConst[X] <: Boolean
type IsConst[+X] <: Boolean
Copy link
Collaborator

Choose a reason for hiding this comment

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

Should we consider leaving this one invariant? IsConst[1] is true, but IsConst[Int] is false

@mbovel mbovel merged commit 123caff into scala:main Feb 28, 2022
@mbovel mbovel deleted the mb/compiletime-ops-covariant branch February 28, 2022 08:44
mbovel added a commit to dotty-staging/dotty that referenced this pull request May 23, 2022
mbovel added a commit that referenced this pull request Jun 15, 2022
…s-covariance

Revert #14452 and make compile-time operations on stable arguments stable
bishabosha pushed a commit to dotty-staging/dotty that referenced this pull request Oct 18, 2022
@Kordyjan Kordyjan added this to the 3.1.3 milestone Aug 2, 2023
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.

None yet

6 participants