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

Permit higher-ranked qualifiers to enclose the self type #20022

Closed
nikomatsakis opened this issue Dec 19, 2014 · 6 comments · Fixed by #21961
Closed

Permit higher-ranked qualifiers to enclose the self type #20022

nikomatsakis opened this issue Dec 19, 2014 · 6 comments · Fixed by #21961
Assignees
Labels
A-type-system Area: Type system
Milestone

Comments

@nikomatsakis
Copy link
Contributor

There is a need to permit for qualifiers that appear in more places. In particular, I'd like to be able to write something like this:

where for<'a, 'b> &'a T : Foo<&'b T>

but today the parser only accepts for after the :. the rest of the code already considers 'a and 'b to be in scope for the self-type of the trait, so it's just the parser that has to be changed. I imagine that the for, in that case, would distribute over all the attached where clauses, so:

where for<'a> T : Foo<&'a T> + Bar<&'a T>

would be equivalent to:

where T : for<'a> Foo<&'a T> + for<'a> Bar<&'a T>

Nested for qualifiers would be illegal, I think:

where for<'a> T : for<'b> Foo<&'a &'b T> // ERROR
@brson brson mentioned this issue Dec 19, 2014
7 tasks
@jroesch
Copy link
Member

jroesch commented Dec 20, 2014

@nikomatsakis you mentioned filling an RFC for this behavior + impossible impls, should we follow up on that or hold off until we close the rest of the issues. It seems like a relatively succinct set of changes.

@kmcallister kmcallister added the A-type-system Area: Type system label Jan 16, 2015
@nikomatsakis nikomatsakis added this to the 1.0 beta milestone Jan 29, 2015
@nikomatsakis
Copy link
Contributor Author

I am placing this on the beta milestone due to the importance for working with bigints and the like.

cc @aturon

@nikomatsakis
Copy link
Contributor Author

There are some minor syntactic issues to work out. My preference would be to accept only the simplest possible form:

  • for<'a> Type : Trait<...>

We would not accept any of the following:

  • for<'a> Type : Trait<...> + Trait2<..> -- what is the scope of the for here?
  • for<'a> Type : for<'b> Trait<..> -- are these union'd or what?

@nrc nrc self-assigned this Feb 4, 2015
@nrc
Copy link
Member

nrc commented Feb 5, 2015

Fixing this is exposing quite a lot of sadness, mostly around the representation of trait refs. I am currently trying to resist the temptation to fix it properly because that seems like a lot of work and touches a lot of complex parts of the compiler.

So, currently part of a where clause such as T: for<'a> U is represented as Binder, where T is encoded inside the trait ref as part of the substs on U. This is cute, but ultimately annoying because it glosses over the scope of the for quantifier - it should be inside the constraint, but outside the trait ref, but such a placing doesn't exist since the trait ref includes the constraint and the only binding scope is outside the trait ref.

This is probably OK for most of the compiler - it is fine to extend the scope of the quantifier. But lifetime resolution needs the precise scope. There doesn't seem to be a nice way to coelesce the lifetimes bound in the two places (T: for<'a> U vs for<'a> T: U) during lifetime resolution, but that seems to be the nicest solution here (or at least the one which changes the least amount of code).

@nikomatsakis
Copy link
Contributor Author

On Wed, Feb 04, 2015 at 06:43:56PM -0800, Nick Cameron wrote:

So, currently part of a where clause such as T: for<'a> U is represented as Binder, where T is encoded inside the trait ref as part of the substs on U. This is cute, but ultimately annoying because it glosses over the scope of the for quantifier - it should be inside the constraint, but outside the trait ref, but such a placing doesn't exist since the trait ref includes the constraint and the only binding scope is outside the trait ref.

This is by design, yes, in anticipation of wanting to support precisely this feature.

This is probably OK for most of the compiler - it is fine to extend the scope of the quantifier. But lifetime resolution needs the precise scope. There doesn't seem to be a nice way to coelesce the lifetimes bound in the two places (T: for<'a> U vs for<'a> T: U) during lifetime resolution, but that seems to be the nicest solution here (or at least the one which changes the least amount of code).

Perhaps we should chat about this live, probably easier. Lifetime
resolution is driven by the AST, which can be structured
differently. It is certainly possible to collapse multiple binders but
I think we should probably just avoid having to, which is what I was
getting at with this comment

@nikomatsakis
Copy link
Contributor Author

Oh, I see your PR now, guess it's a moot point.

nrc added a commit to nrc/rust that referenced this issue Feb 9, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-type-system Area: Type system
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants