-
-
Notifications
You must be signed in to change notification settings - Fork 414
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
Improve error message for failure of generic subtyping of concrete types #4514
Comments
The code in question is something under the |
So the code is definitely being asked to check if @jemc can you explain to me how this is correct based on the current type system? I would expect the test to be "is val a subtype of box". |
I gave some explanation in the sync call. For anyone who wants to understand this issue, I recommend reading first this RFC that I made, proposing a new language feature related to this topic. The RFC stalled because Sylvan suggested that this problem is better solved by HKT (higher-kinded types), but there is no RFC for HKT at this time. To summarize, the key reason why the code from @chalcolith doesn't work is because in Pony, generic classes require identical type parameters for subtyping. In other words, type parameters are always treated as invariant for generic classes/actors/primitives. That's because Pony's type system "assumes the worst" about expecting that the class/actor/primitive can use the type parameter in uses both "covariant positions" (e.g. return types) and "contravariant positions" (e.g. parameter types), meaning that the type parameter is treated as invariant. And in fact Pony's "assume the worst" expectation turns out to be true for The way to make this work in Pony is to use an The RFC I linked above was about a new syntax for automatically "summoning" an interface type which included only the covariant or only the contravariant (or only the bivariant) methods of the relevant class, without you needing to define such an interface by hand. If that RFC were to be accepted/implemented, you'd be able to use |
Regarding the error message shown in @chalcolith 's code above, I think the error message is correct and understandable, as long as you know the background about Pony concrete types (classes/actors/primitives) always using their type parameters in an invariant way (never covariant, contravariant, or bivariant). If you want covariance/contravariance/bivariance you need to use a correctly-defined interface type that matches the relevant methods of the class. To improve the error message I guess we could try to say something to that effect as a "hint" after the current message says "Array[B val] val has different type arguments than Array[B box] box^". |
Can this be closed? |
If somebody thinks we should improve the error message for Otherwise, yes, it can be closed. |
The error isn't coming from the typeargs check. That passes just fine. The error is from the sub cap and ephemeral check. |
I'm talking about this error message, which is emitted from the |
The following program:
https://playground.ponylang.io/?gist=5cdad1a2e82f962b034e277e23d1a91f
Produces the errors:
Where the compiler is not allowing us to pass an
Array[B val]
to a parameter of typeArray[B box]
. It would be nice to allow covariance for type parameters' capabilities so that we could do this.The code in question seems to be
ponyc/src/libponyc/type/subtype.c
Line 836 in cb2f814
The text was updated successfully, but these errors were encountered: