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

Implement where clauses #17657

Open
brson opened this Issue Sep 30, 2014 · 6 comments

Comments

Projects
None yet
7 participants
@brson
Copy link
Contributor

brson commented Sep 30, 2014

Tracking rust-lang/rfcs#135.

Task list:

  • PR #20002: Parse and process where clauses not attached to parameters.
  • #20019: Reject where clauses that do not mention a type parameter.
  • #20020: Check that the bounds of impl are implied by trait in a more general way.
  • #20023: Parse and accept outlives expressions in where clauses.
  • #20021: Permit unsatisfiable methods to be omitted.
  • #20022: Permit higher-ranked qualifiers to enclose the self type
  • #20041: Accept type equality constraints in where clauses
@pnkfelix

This comment has been minimized.

Copy link
Member

pnkfelix commented Oct 2, 2014

P-backcompat-libs, but not 1.0.

@nikomatsakis nikomatsakis referenced this issue Oct 10, 2014

Closed

Trait reform #5527

3 of 5 tasks complete
@nikomatsakis

This comment has been minimized.

Copy link
Contributor

nikomatsakis commented Oct 10, 2014

I've been working on this somewhat in the background. The patch is somewhat more involved than I imagined initially because where clauses are more powerful than I initially imagined -- in particular, there are lots of bits of code that assume that there is an intrinsic set of bounds associated with a specific type parameter, whereas where clauses make those things scope dependent. We've been steadily removed them and by now all the deep connections are almost entirely eradicated (@pcwalton's work in #17864 is, I think, the last bit).

In my branch, I was removing all the lists of bounds from type parameters and adding in a list of predicates instead. It occurred to me today that it might also be possible to phase support for this in faster by doing it in two stages: first, leaving the code as is but adding a generalized list of predicates, and then removing the bounds lists. I'm not sure which is better.

@jroesch

This comment has been minimized.

Copy link
Member

jroesch commented Oct 24, 2014

@nikomatsakis I'm looking into this after our conversation this morning. Let me know if there are any other tracking issues I should be following. I am going to go dig up your branch and work on it during the afternoon session.

@jroesch

This comment has been minimized.

Copy link
Member

jroesch commented Dec 22, 2014

@nikomatsakis would it be possible to update the check list at some point? would be good to check at glance what remains. It is fine if it happens after #20020 lands.

@aturon

This comment has been minimized.

Copy link
Member

aturon commented Jan 8, 2015

Nominating for removal from P-backcompat-libs; enough has landed for us to already roll this out.

@aturon aturon added the I-nominated label Jan 8, 2015

@pnkfelix

This comment has been minimized.

Copy link
Member

pnkfelix commented Jan 8, 2015

removing from P-backcompat-libs (since the back compat stuff is done). P-high.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.