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
Covariance propagation across functors #7212
Comments
This issue has been open one year with no activity. Consequently, it is being marked with the "stale" label. What this means is that the issue will be automatically closed in 30 days unless more comments are added or the "stale" label is removed. Comments that provide new information on the issue are especially welcome: is it still reproducible? did it appear in other contexts? how critical is it? etc. |
That is a long standing issue. It would help if somebody could document where it hurts. |
Well, as tyxml demonstrate, everytime you have something parametrized by a notion of collection that is instantiated (many collections are covariant, but not all), and you use it through the abstract API. I suspect this will hurt even more with modular (explicit|implicits) .... |
This issue has been open one year with no activity. Consequently, it is being marked with the "stale" label. What this means is that the issue will be automatically closed in 30 days unless more comments are added or the "stale" label is removed. Comments that provide new information on the issue are especially welcome: is it still reproducible? did it appear in other contexts? how critical is it? etc. |
My understanding is that fixing this would require re-computing the properties (variance, etc.) of type declarations when they are changed by a substitution. I don't understand if this would have a negative performance impact; in theory this is a fixpoint, in practice we can start from the previously-computed properties so in the common case (no change) a single iteration should be enough. I also don't know if this is very difficult to implement (it is probably easier now that we are working on better signature-item grouping logic, see #10401), or just nobody has been able to put the effort of pulling this important change and evaluating it. In general for type properties there are two schools:
Note that the present issue only affects declaration-time properties, not on-demand properties (that are recomputed anew on functor instances, where expansions "see" the functor argument), and that has been used as an argument to switch property computation to the on-demand style rather than declaration-time style (see #10017, #10041). I would be interested to know if this limitation of the declaration-time approach can be fixed, because it influences the design/implementation of all type properties. (For some properties the on-demand style is obviously fine performance-wise, because checking is very rare. This is typically the case of immediacy, which is thus a good candidate for on-demand mode. But for variance it's not clear that we would like to perform computations on each subtyping coercion. (Or, for unboxed constructors, on each compilation of the constructor used as a pattern.) So maybe the on-demand style should consider caching seriously, possibly by caching the result in the type declaration itself. But caching is only possible if the property is formulated in a parametrization-friendly way, so that we can compute the property of parametrized types parametrized over the property of its type parameters.) |
This issue has been open one year with no activity. Consequently, it is being marked with the "stale" label. What this means is that the issue will be automatically closed in 30 days unless more comments are added or the "stale" label is removed. Comments that provide new information on the issue are especially welcome: is it still reproducible? did it appear in other contexts? how critical is it? etc. |
Long standing problem |
This issue has been open one year with no activity. Consequently, it is being marked with the "stale" label. What this means is that the issue will be automatically closed in 30 days unless more comments are added or the "stale" label is removed. Comments that provide new information on the issue are especially welcome: is it still reproducible? did it appear in other contexts? how critical is it? etc. |
Original bug ID: 7212
Reporter: @Drup
Assigned to: @garrigue
Status: acknowledged (set by @damiendoligez on 2016-04-05T14:20:18Z)
Resolution: open
Priority: normal
Severity: feature
Target version: later
Category: typing
Related to: #5984
Monitored by: @Drup
Bug description
In the attached file, one can see that covariance doesn't seem propagated across type aliases with functors. The behavior leads to rather surprising behaviors.
This appeared in a "real" situation in tyxml where we have a wrapping interface that is sometimes instantiated with covariant types:
Maybe related (thanks yallop): #5984
File attachments
The text was updated successfully, but these errors were encountered: