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
type constraints alter signatures in unusual ways #6528
Comments
Comment author: @garrigue Unification on types with only an upper bound can be tricky. |
Comment author: @garrigue Proving the equality for these types would require a new algorithm detecting that these types are actually equivalent because the type variables do not appear anywhere else in the types. |
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: 6528
Reporter: mkoconnor
Assigned to: @garrigue
Status: acknowledged (set by @damiendoligez on 2014-09-15T13:22:18Z)
Resolution: open
Priority: normal
Severity: feature
Version: 4.01.0
Target version: later
Category: typing
Monitored by: @gasche @garrigue
Bug description
I'm not sure exactly what to call this (or if this is in fact a bug) but the following two compilation errors surprised me and seem related: In the first, a value is annotated as having a type exactly as it appears in the signature. That type-checks, but the module still fails to compile.
In the second, you are not allowed to replace one type constraints with the same type and the same constraints:
(Obviously, in that example, in real life it wouldn't be the same signature twice but two different signatures still having the same constraint on their type.)
The text was updated successfully, but these errors were encountered: