-
Notifications
You must be signed in to change notification settings - Fork 182
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
preliminary model for "opaque types" where hidden types are known #335
Comments
Let's create a check-list of details to take care of (edit: checklist moved by detrumi to keep it updated) |
How about this (comment in the |
Checklist
(moved the checklist to my own comment to avoid "nikomatsakis mentioned ..." messages when editing the checklist to refer to PRs) |
Only one task left: extend WF rules for implied bounds interactions. I can't quite remember what we meant with that, but I think it's something along these lines: Given this program:
Using implied bounds, this can prove the following (see the implied_bounds test):
The same should hold for opaque types, but doesn't:
We might be missing some more WF checks around opaque types, since the program above fails to prove the goal, but only does the WF check once you add |
The goal here is to model Rust's
impl Trait
. For now the starting plan is to have a version where chalk is given both the opaque type declaration and the hidden type:Note that opaque types can be generic.
We will model opaque types as an special kind of alias. Like associated types aliases, when an opaque type alias
T
is equated with some other typeU
, we will generate anAliasEq(T = U)
goal.The difference is that the two clauses for
AliasEq
goals work a bit differently. In particular, the "normalization" rule requires a special goal,Reveal
, to be in the environment:There are also special rules for the
!T
placeholder:The text was updated successfully, but these errors were encountered: