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
Small inconsistency with relaxed value restriction, polymorphic variants and signature inclusion check #7817
Comments
Comment author: mandrykin Just as an example where this can matter. If I use a (covariant) phantom type parameter for encoding mutability/immutability the following way: |
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. |
As opposed to being stale, or even a principality issue, this is a soundness bug:
|
@garrigue to make sure he sees this. |
Could this issue be assigned to someone, please? |
Original bug ID: 7817
Reporter: mandrykin
Status: new
Resolution: open
Priority: low
Severity: tweak
Platform: x86_64 Linux 4.4.0
OS: Ubuntu
OS Version: 16.04.4 LTS
Version: 4.06.1
Category: typing
Monitored by: @nojb @yallop
Bug description
For this example:
Normally, the inferred type is
i.e. with a weak type variable as the relaxed value restriction works only for strictly covariant positions. However,
gives
(polymorphic type). As far as I understand this interferes with principality as
Can be given the type
but also
which has type
and neither of the types is more general. The behavior occurs with upper bounded polymorphic variants (
[<
]) arbitrarily nested into other types in covariant positions both in usual and -principal modes. I'm actually currently writing some code, where this behavior turned out to be beneficial allowing the polymorphic types where they were actually needed without resorting to explicitly polymorphic record fields/object methods. But the question is whether this is reliable and if someone is going to eventually notice and change this or this can be admitted as a feature.The text was updated successfully, but these errors were encountered: