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
Unable to add multiple constraints/equations to a type #7544
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. |
@garrigue Is this in the class of things that can't really be fixed with the current implementation? I suspect that it might be, but I'd appreciate you confirming that before I close the issue. |
Not really. I long thought that it would require changing the behaviour of the expansion of type abbreviations in a row variable position, but actually the more reasonable approach is to have the expansion of this abbreviation replace the whole variant type (which is what is already done in includecore), since we want it to control the presence flag of all fields too. However, this means checking for possible replacement of the whole row in lots of places, possibly all occurrences of |
This said, I'm not too much excited by all the chances of bugs it will introduce. |
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. |
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: 7544
Reporter: roshanjames
Status: acknowledged (set by @mshinwell on 2017-06-02T14:42:49Z)
Resolution: open
Priority: normal
Severity: feature
Category: typing
Monitored by: @lpw25
Bug description
In the code below,
f
does not compile and producesbecause OCaml is unable to constrain the type of [m] from
[[< `A | `B] M.t]
to[[`A] M.t]
or[[`B] M.t]
in each branch of thematch.
Here is one more program that fails for the same reason, which wasn't
as obvious to me initially (I got this one from Leo White):
Here
bar1
compiles, butbar2
does not:The text was updated successfully, but these errors were encountered: