-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
Higher-ranked subtyping is too strict #33684
Comments
nikomatsakis
added
the
T-lang
Relevant to the language team, which will review and decide on the PR/issue.
label
May 17, 2016
nikomatsakis
added a commit
to nikomatsakis/rust
that referenced
this issue
Aug 31, 2017
nikomatsakis
added a commit
to nikomatsakis/rust
that referenced
this issue
Sep 12, 2017
nikomatsakis
added a commit
to nikomatsakis/rust
that referenced
this issue
Nov 9, 2017
This was referenced Feb 21, 2018
nikomatsakis
added a commit
to nikomatsakis/rust
that referenced
this issue
Mar 19, 2018
nikomatsakis
added a commit
to nikomatsakis/rust
that referenced
this issue
Jun 25, 2018
As the comment explains, this is needed to prevent subtype from going awry in higher-ranked cases, due to rust-lang#33684. The proper fix here is introducing universes (rust-lang#48536).
nikomatsakis
added a commit
to nikomatsakis/rust
that referenced
this issue
Jun 26, 2018
As the comment explains, this is needed to prevent subtype from going awry in higher-ranked cases, due to rust-lang#33684. The proper fix here is introducing universes (rust-lang#48536).
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Branching off from #32330. The current subtyping rules for higher-ranked regions are overly conservative, with the result that a function declaration like this:
is not equivalent to
This exaggerates the impact of #32330 because functions like
must be converted to the form
in some cases, which feels a bit silly.
I proposed a fix in #32330 (described in some detail here), however I decided to hold off and land that fix separately, when I had more time to polish it (and consider it). In the meantime, this does mean that we wind up with more warnings than we otherwise would.
There is some mild backcompat risk in that the current coherence rules will allow you to distinguish between types on the basis of bound regions, but in some cases that is wrong. It is probably worth modifying coherence so that it doesn't distinguish bound regions at all -- or better yet, operates with fully erased regions.
The text was updated successfully, but these errors were encountered: