Skip to content
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

add a (in-scope (type ty)) predicate for types #59

Open
nikomatsakis opened this issue Jun 17, 2022 · 0 comments
Open

add a (in-scope (type ty)) predicate for types #59

nikomatsakis opened this issue Jun 17, 2022 · 0 comments

Comments

@nikomatsakis
Copy link
Contributor

Right now, when a function or impl is supposed to get "implied bounds" from a type Foo, we add (well-formed (type Foo)) to the environment. In the "expanded implied bounds" proposal this made sense, but it doesn't work well for modeling the more limited version of implied bounds that rust uses. For example, this function is not well-formed in rustc today:

struct WantsOrd<T: Ord>(T);

fn foo<T>(x: WantsOrd<T>) { }

fn main() { }

Compiling it gives an error because T: Ord is required (playground).

But in a-mir-formality, we would have trouble producing this error: we would try to prove (well-formed (type (user-ty (WantsOrd T)))) but that is also in the environment, so it would be true.

To solve this, I think we should add a new predicate, (in-scope (ParameterKind Parameter)). This would be added to the environment for a function and it would also have to be proven when invoking a function (these are basically implied where-clauses, though we have no where-clause syntax for it). We would have a built-in rule that says:

(in-scope (ParameterKind Parameter)) :- (well-formed (ParameterKind Parameter))

and we would create the invariants based on in-scope (so, with expanded implied bounds, we would say that, for all T, (in-scope (type (user-ty (WantsOrd T)))) => (is-implemented (Ord T)), for example).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant