Implementation of GATs outlives lint #89970

jackh726 · 2021-10-17T00:05:53Z

See #87479 for background. Closes #87479

The basic premise of this lint/error is to require the user to write where clauses on a GAT when those bounds can be implied or proven from any function on the trait returning that GAT.

Intuitive Explanation (Attempt)

Let's take this trait definition as an example:

trait Iterable {
    type Item<'x>;
    fn iter<'a>(&'a self) -> Self::Item<'a>;
}

Let's focus on the iter function. The first thing to realize is that we know that Self: 'a because of &'a self. If an impl wants Self::Item to contain any data with references, then those references must be derived from &'a self. Thus, they must live only as long as 'a. Furthermore, because of the Self: 'a implied bound, they must live only as long as Self. Since it's 'a is used in place of 'x, it is reasonable to assume that any value of Self::Item<'x>, and thus 'x, will only be able to live as long as Self. Therefore, we require this bound on Item in the trait.

As another example:

trait Deserializer<T> {
    type Out<'x>;
    fn deserialize<'a>(&self, input: &'a T) -> Self::Out<'a>;
}

The intuition is similar here, except rather than a Self: 'a implied bound, we have a T: 'a implied bound. Thus, the data on Self::Out<'a> is derived from &'a T, and thus it is reasonable to expect that the lifetime 'x will always be less than T.

Implementation Algorithm

Given a GAT <P0 as Trait<P1..Pi>>::G<Pi...Pn> declared as trait T<A1..Ai> for A0 { type G<Ai...An>; } used in return type of one associated function F
Given env E (including implied bounds) for F
For each lifetime parameter 'a in P0...Pn:
- For each other type parameter Pi != 'a in P0...Pn: // FIXME: this include of lifetime parameters too
  - If E => (P: 'a):
    - Require where clause Ai: 'a

Follow-up questions

What should we do when we don't pass params exactly?
For this example:

trait Des {
    type Out<'x, D>;
    fn des<'z, T>(&self, data: &'z Wrap<T>) -> Self::Out<'z, Wrap<T>>;
}

Should we be requiring a D: 'x clause? We pass Wrap<T> as D and 'z as 'x, and should be able to prove that Wrap<T>: 'z.

r? @nikomatsakis

nikomatsakis

Hi @jackh726 -- left a bunch of comments, mostly nits. The most significant one is the question of what to do in the case of multiple functions.

compiler/rustc_typeck/src/check/wfcheck.rs

nikomatsakis · 2021-10-25T14:58:38Z

src/test/ui/generic-associated-types/issue-86787.stderr

@@ -1,32 +1,10 @@
-error: `impl` associated type signature for `TRef` doesn't match `trait` associated type signature
-  --> $DIR/issue-86787.rs:23:5
+error: Missing required bounds on TRef


nit: lowercase letter

I think we can do more to give an intuitive understanding here. I'd like the message to be something like this...

error: associated type `TRef` must declare that it may borrow from `Self` --> $DIR/issue-86787.rs:11:5 | LL | type TRef<'a>; | ^^^^^^^^^^^^^- | | | help: add the required where clauses: `where Self: 'a` LL | fn ref_children<'a>(&'a self) -> Vec<Self::TRef<'a>>; | ^^^^^^^^^^^^ | | | in this function, `TRef` could return content from the type `Self`, borrowed for `'a` note: This where clause is required because we expect to add it as a default in the future. If adding this where clause causes your use case not to work, please visit https://rust-lang.github.io/generic-associated-types-initiative/ to give feedback (and to see the workaround).

Obviously these spans are not as precise as they could be, and the wording can probably be improved. I was trying to give what seemed like a realistic message based on the content we currently have available

src/test/ui/generic-associated-types/self-outlives-lint.rs

nikomatsakis · 2021-10-25T15:28:47Z

Had a thought as I was writing the explainer:

We might need to extend these errors. Consider this case:

trait Iterable {
    type Item<'a>;

    type Iterator<'a>: Iterator<Item = Self::Item<'a>>;

    fn iter<'a>(&'a self) -> Self::Iterator<'a>;
}

Here, the method implies that Iterator needs where Self: 'a, but Item does too. I think we can see that from the fact that references to Item<'a> appear in the bounds of Iterator, and we inferred that 'a represents the "lifetime of a borrow from Self" when using Iterator, so it probably does for Item too.

jackh726 · 2021-11-01T03:08:29Z

src/test/ui/generic-associated-types/self-outlives-lint.stderr

+LL |     type Bar<'b>;
+   |     ^^^^^^^^^^^^-
+   |                 |
+   |                 help: add the required where clauses: `where Self: 'b, Self: 'a`


This isn't right

jackh726 · 2021-11-01T03:08:40Z

src/test/ui/generic-associated-types/self-outlives-lint.stderr

+LL |     type Bar<'b>;
+   |     ^^^^^^^^^^^^-
+   |                 |
+   |                 help: add the required where clauses: `where Self: 'b, Self: 'a`


jackh726 · 2021-11-01T03:12:29Z

@nikomatsakis I've addressed the nits here. But have not yet reworked the diagnostic. I also added checking for region outlives region. I have not started working out the Iterable case and there tests where we have a lifetime on the trait, not the method could be cleaned up a bit (currently require Self: 'a and Self: 'b, when really we probably should pick one...maybe the trait parameter name)

nikomatsakis

OK, this is looking pretty clean right now. r=me with the various comments addressed (or with FIXMEs created). I know it's not in the complete end state we want, but I'd also be ok to land it and iterate in tree.

nikomatsakis · 2021-11-05T20:41:03Z

compiler/rustc_typeck/src/check/wfcheck.rs

+/// Require that the user writes as where clauses on GATs the implicit
+/// outlives bounds involving trait parameters in trait functions and


Suggested change

/// Require that the user writes as where clauses on GATs the implicit

/// outlives bounds involving trait parameters in trait functions and

/// Require that the user writes where clauses on GATs for the implicit

/// outlives bounds involving trait parameters in trait functions and

compiler/rustc_typeck/src/check/wfcheck.rs

jackh726 · 2021-11-06T02:32:45Z

@bors r=nikomatsakis

bors · 2021-11-06T02:32:47Z

📌 Commit b6edcbd has been approved by nikomatsakis

bors · 2021-11-06T04:15:30Z

⌛ Testing commit b6edcbd with merge 9d39f6a...

bors · 2021-11-06T07:14:59Z

☀️ Test successful - checks-actions
Approved by: nikomatsakis
Pushing 9d39f6a to master...

rust-timer · 2021-11-06T08:57:17Z

Finished benchmarking commit (9d39f6a): comparison url.

Summary: This benchmark run did not return any relevant changes.

If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf.

@rustbot label: -perf-regression

Broken due to rust-lang/rust#89970

jackh726 · 2021-11-08T18:42:34Z

@MingweiSamuel this is weird...maybe try to cargo clean and rebuild?

…er-errors Stabilize generic associated types Closes rust-lang#44265 r? `@nikomatsakis` # ⚡ Status of the discussion ⚡ * [x] There have been several serious concerns raised, [summarized here](rust-lang#96709 (comment)). * [x] There has also been a [deep-dive comment](rust-lang#96709 (comment)) explaining some of the "patterns of code" that are enabled by GATs, based on use-cases posted to this thread or on the tracking issue. * [x] We have modeled some aspects of GATs in [a-mir-formality](https://github.com/nikomatsakis/a-mir-formality) to give better confidence in how they will be resolved in the future. [You can read a write-up here](https://github.com/rust-lang/types-team/blob/master/minutes/2022-07-08-implied-bounds-and-wf-checking.md). * [x] The major points of the discussion have been [summarized on the GAT initiative repository](https://rust-lang.github.io/generic-associated-types-initiative/mvp.html). * [x] [FCP has been proposed](rust-lang#96709 (comment)) and we are awaiting final decisions and discussion amidst the relevant team members. # Stabilization proposal This PR proposes the stabilization of `#![feature(generic_associated_types)]`. While there a number of future additions to be made and bugs to be fixed (both discussed below), properly doing these will require significant language design and will ultimately likely be backwards-compatible. Given the overwhelming desire to have some form of generic associated types (GATs) available on stable and the stability of the "simple" uses, stabilizing the current subset of GAT features is almost certainly the correct next step. Tracking issue: rust-lang#44265 Initiative: https://rust-lang.github.io/generic-associated-types-initiative/ RFC: https://github.com/rust-lang/rfcs/blob/master/text/1598-generic_associated_types.md Version: 1.65 (2022-08-22 => beta, 2022-11-03 => stable). ## Motivation There are a myriad of potential use cases for GATs. Stabilization unblocks probable future language features (e.g. async functions in traits), potential future standard library features (e.g. a `LendingIterator` or some form of `Iterator` with a lifetime generic), and a plethora of user use cases (some of which can be seen just by scrolling through the tracking issue and looking at all the issues linking to it). There are a myriad of potential use cases for GATs. First, there are many users that have chosen to not use GATs primarily because they are not stable (some of which can be seen just by scrolling through the tracking issue and looking at all the issues linking to it). Second, while language feature desugaring isn't *blocked* on stabilization, it gives more confidence on using the feature. Likewise, library features like `LendingIterator` are not necessarily blocked on stabilization to be implemented unstably; however few, if any, public-facing APIs actually use unstable features. This feature has a long history of design, discussion, and developement - the RFC was first introduced roughly 6 years ago. While there are still a number of features left to implement and bugs left to fix, it's clear that it's unlikely those will have backwards-incompatibility concerns. Additionally, the bugs that do exist do not strongly impede the most-common use cases. ## What is stabilized The primary language feature stabilized here is the ability to have generics on associated types, as so. Additionally, where clauses on associated types will now be accepted, regardless if the associated type is generic or not. ```rust trait ATraitWithGATs { type Assoc<'a, T> where T: 'a; } trait ATraitWithoutGATs<'a, T> { type Assoc where T: 'a; } ``` When adding an impl for a trait with generic associated types, the generics for the associated type are copied as well. Note that where clauses are allowed both after the specified type and before the equals sign; however, the latter is a warn-by-default deprecation. ```rust struct X; struct Y; impl ATraitWithGATs for X { type Assoc<'a, T> = &'a T where T: 'a; } impl ATraitWithGATs for Y { type Assoc<'a, T> where T: 'a = &'a T; } ``` To use a GAT in a function, generics are specified on the associated type, as if it was a struct or enum. GATs can also be specified in trait bounds: ```rust fn accepts_gat<'a, T>(t: &'a T) -> T::Assoc<'a, T> where for<'x> T: ATraitWithGATs<Assoc<'a, T> = &'a T> { ... } ``` GATs can also appear in trait methods. However, depending on how they are used, they may confer where clauses on the associated type definition. More information can be found [here](rust-lang#87479). Briefly, where clauses are required when those bounds can be proven in the methods that *construct* the GAT or other associated types that use the GAT in the trait. This allows impls to have maximum flexibility in the types defined for the associated type. To take a relatively simple example: ```rust trait Iterable { type Item<'a>; type Iterator<'a>: Iterator<Item = Self::Item<'a>>; fn iter<'x>(&'x self) -> Self::Iterator<'x>; //^ We know that `Self: 'a` for `Iterator<'a>`, so we require that bound on `Iterator` // `Iterator` uses `Self::Item`, so we also require a `Self: 'a` on `Item` too } ``` A couple well-explained examples are available in a previous [blog post](https://blog.rust-lang.org/2021/08/03/GATs-stabilization-push.html). ## What isn't stabilized/implemented ### Universal type/const quantification Currently, you can write a bound like `X: for<'a> Trait<Assoc<'a> = &'a ()>`. However, you cannot currently write `for<T> X: Trait<Assoc<T> = T>` or `for<const N> X: Trait<Assoc<N> = [usize; N]>`. Here is an example where this is needed: ```rust trait Foo {} trait Trait { type Assoc<F: Foo>; } trait Trait2: Sized { fn foo<F: Foo, T: Trait<Assoc<F> = F>>(_t: T); } ``` In the above example, the *caller* must specify `F`, which is likely not what is desired. ### Object-safe GATs Unlike non-generic associated types, traits with GATs are not currently object-safe. In other words the following are not allowed: ```rust trait Trait { type Assoc<'a>; } fn foo(t: &dyn for<'a> Trait<Assoc<'a> = &'a ()>) {} //^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ not allowed let ty: Box<dyn for<'a> Trait<Assoc<'a> = &'a ()>>; //^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ not allowed ``` ### Higher-kinded types You cannot write currently (and there are no current plans to implement this): ```rust struct Struct<'a> {} fn foo(s: for<'a> Struct<'a>) {} ``` ## Tests There are many tests covering GATs that can be found in `src/test/ui/generic-associated-types`. Here, I'll list (in alphanumeric order) tests highlight some important behavior or contain important patterns. - `./parse/*`: Parsing of GATs in traits and impls, and the trait path with GATs - `./collections-project-default.rs`: Interaction with associated type defaults - `./collections.rs`: The `Collection` pattern - `./const-generics-gat-in-trait-return-type-*.rs`: Const parameters - `./constraint-assoc-type-suggestion.rs`: Emit correct syntax in suggestion - `./cross-crate-bounds.rs`: Ensure we handles bounds across crates the same - `./elided-in-expr-position.rs`: Disallow lifetime elision in return position - `./gat-in-trait-path-undeclared-lifetime.rs`: Ensure we error on undeclared lifetime in trait path - `./gat-in-trait-path.rs`: Base trait path case - `./gat-trait-path-generic-type-arg.rs`: Don't allow shadowing of parameters - `./gat-trait-path-parenthesised-args.rs`: Don't allow paranthesized args in trait path - `./generic-associated-types-where.rs`: Ensure that we require where clauses from trait to be met on impl - `./impl_bounds.rs`: Check that the bounds on GATs in an impl are checked - `./issue-76826.rs`: `Windows` pattern - `./issue-78113-lifetime-mismatch-dyn-trait-box.rs`: Implicit 'static diagnostics - `./issue-84931.rs`: Ensure that we have a where clause on GAT to ensure trait parameter lives long enough - `./issue-87258_a.rs`: Unconstrained opaque type with TAITs - `./issue-87429-2.rs`: Ensure we can use bound vars in the bounds - `./issue-87429-associated-type-default.rs`: Ensure bounds hold with associated type defaults, for both trait and impl - `./issue-87429-specialization.rs`: Check that bounds hold under specialization - `./issue-88595.rs`: Under the outlives lint, we require a bound for both trait and GAT lifetime when trait lifetime is used in function - `./issue-90014.rs`: Lifetime bounds are checked with TAITs - `./issue-91139.rs`: Under migrate mode, but not NLL, we don't capture implied bounds from HRTB lifetimes used in a function and GATs - `./issue-91762.rs`: We used to too eagerly pick param env candidates when normalizing with GATs. We now require explicit parameters specified. - `./issue-95305.rs`: Disallow lifetime elision in trait paths - `./iterable.rs`: `Iterable` pattern - `./method-unsatified-assoc-type-predicate.rs`: Print predicates with GATs correctly in method resolve error - `./missing_lifetime_const.rs`: Ensure we must specify lifetime args (not elidable) - `./missing-where-clause-on-trait.rs`: Ensure we don't allow stricter bounds on impl than trait - `./parameter_number_and_kind_impl.rs`: Ensure paramters on GAT in impl match GAT in trait - `./pointer_family.rs`: `PointerFamily` pattern - `./projection-bound-cycle.rs`: Don't allow invalid cycles to prove bounds - `./self-outlives-lint.rs`: Ensures that an e.g. `Self: 'a` is written on the traits GAT if that bound can be implied from the GAT usage in the trait - `./shadowing.rs`: Don't allow lifetime shadowing in params - `./streaming_iterator.rs`: `StreamingIterator`(`LendingIterator`) pattern - `./trait-objects.rs`: Disallow trait objects for traits with GATs - `./variance_constraints.rs`: Require that GAT substs be invariant ## Remaining bugs and open issues A full list of remaining open issues can be found at: https://github.com/rust-lang/rust/labels/F-generic_associated_types There are some `known-bug` tests in-tree at `src/test/ui/generic-associated-types/bugs`. Here I'll categorize most of those that GAT bugs (or involve a pattern found more with GATs), but not those that include GATs but not a GAT issue in and of itself. (I also won't include issues directly for things listed elsewhere here.) Using the concrete type of a GAT instead of the projection type can give errors, since lifetimes are chosen to be early-bound vs late-bound. - rust-lang#85533 - rust-lang#87803 In certain cases, we can run into cycle or overflow errors. This is more generally a problem with associated types. - rust-lang#87755 - rust-lang#87758 Bounds on an associatd type need to be proven by an impl, but where clauses need to be proven by the usage. This can lead to confusion when users write one when they mean the other. - rust-lang#87831 - rust-lang#90573 We sometimes can't normalize closure signatures fully. Really an asociated types issue, but might happen a bit more frequently with GATs, since more obvious place for HRTB lifetimes. - rust-lang#88382 When calling a function, we assign types to parameters "too late", after we already try (and fail) to normalize projections. Another associated types issue that might pop up more with GATs. - rust-lang#88460 - rust-lang#96230 We don't fully have implied bounds for lifetimes appearing in GAT trait paths, which can lead to unconstrained type errors. - rust-lang#88526 Suggestion for adding lifetime bounds can suggest unhelpful fixes (`T: 'a` instead of `Self: 'a`), but the next compiler error after making the suggested change is helpful. - rust-lang#90816 - rust-lang#92096 - rust-lang#95268 We can end up requiring that `for<'a> I: 'a` when we really want `for<'a where I: 'a> I: 'a`. This can leave unhelpful errors than effectively can't be satisfied unless `I: 'static`. Requires bigger changes and not only GATs. - rust-lang#91693 Unlike with non-generic associated types, we don't eagerly normalize with param env candidates. This is intended behavior (for now), to avoid accidentaly stabilizing picking arbitrary impls. - rust-lang#91762 Some Iterator adapter patterns (namely `filter`) require Polonius or unsafe to work. - rust-lang#92985 ## Potential Future work ### Universal type/const quantification No work has been done to implement this. There are also some questions around implied bounds. ### Object-safe GATs The intention is to make traits with GATs object-safe. There are some design work to be done around well-formedness rules and general implementation. ### GATified std lib types It would be helpful to either introduce new std lib traits (like `LendingIterator`) or to modify existing ones (adding a `'a` generic to `Iterator::Item`). There also a number of other candidates, like `Index`/`IndexMut` and `Fn`/`FnMut`/`FnOnce`. ### Reduce the need for `for<'a>` Seen [here](rust-lang/rfcs#1598 (comment)). One possible syntax: ```rust trait Iterable { type Iter<'a>: Iterator<Item = Self::Item<'a>>; } fn foo<T>() where T: Iterable, T::Item<let 'a>: Display { } //note the `let`! ``` ### Better implied bounds on higher-ranked things Currently if we have a `type Item<'a> where self: 'a`, and a `for<'a> T: Iterator<Item<'a> = &'a ()`, this requires `for<'a> Self: 'a`. Really, we want `for<'a where T: 'a> ...` There was some mentions of this all the back in the RFC thread [here](rust-lang/rfcs#1598 (comment)). ## Alternatives ### Make generics on associated type in bounds a binder Imagine the bound `for<'a> T: Trait<Item<'a>= &'a ()>`. It might be that `for<'a>` is "too large" and it should instead be `T: Trait<for<'a> Item<'a>= &'a ()>`. Brought up in RFC thread [here](rust-lang/rfcs#1598 (comment)) and in a few places since. Another related question: Is `for<'a>` the right syntax? Maybe `where<'a>`? Also originally found in RFC thread [here](rust-lang/rfcs#1598 (comment)). ### Stabilize lifetime GATs first This has been brought up a few times. The idea is to only allow GATs with lifetime parameters to in initial stabilization. This was probably most useful prior to actual implementation. At this point, lifetimes, types, and consts are all implemented and work. It feels like an arbitrary split without strong reason. ## History * On 2016-04-30, [RFC opened](rust-lang/rfcs#1598) * On 2017-09-02, RFC merged and [tracking issue opened](rust-lang#44265) * On 2017-10-23, [Move Generics from MethodSig to TraitItem and ImplItem](rust-lang#44766) * On 2017-12-01, [Generic Associated Types Parsing & Name Resolution](rust-lang#45904) * On 2017-12-15, [https://github.com/rust-lang/rust/pull/46706](https://github.com/rust-lang/rust/pull/46706) * On 2018-04-23, [Feature gate where clauses on associated types](rust-lang#49368) * On 2018-05-10, [Extend tests for RFC1598 (GAT)](rust-lang#49423) * On 2018-05-24, [Finish implementing GATs (Chalk)](rust-lang/chalk#134) * On 2019-12-21, [Make GATs less ICE-prone](rust-lang#67160) * On 2020-02-13, [fix lifetime shadowing check in GATs](rust-lang#68938) * On 2020-06-20, [Projection bound validation](rust-lang#72788) * On 2020-10-06, [Separate projection bounds and predicates](rust-lang#73905) * On 2021-02-05, [Generic associated types in trait paths](rust-lang#79554) * On 2021-02-06, [Trait objects do not work with generic associated types](rust-lang#81823) * On 2021-04-28, [Make traits with GATs not object safe](rust-lang#84622) * On 2021-05-11, [Improve diagnostics for GATs](rust-lang#82272) * On 2021-07-16, [Make GATs no longer an incomplete feature](rust-lang#84623) * On 2021-07-16, [Replace associated item bound vars with placeholders when projecting](rust-lang#86993) * On 2021-07-26, [GATs: Decide whether to have defaults for `where Self: 'a`](rust-lang#87479) * On 2021-08-25, [Normalize projections under binders](rust-lang#85499) * On 2021-08-03, [The push for GATs stabilization](https://blog.rust-lang.org/2021/08/03/GATs-stabilization-push.html) * On 2021-08-12, [Detect stricter constraints on gats where clauses in impls vs trait](rust-lang#88336) * On 2021-09-20, [Proposal: Change syntax of where clauses on type aliases](rust-lang#89122) * On 2021-11-06, [Implementation of GATs outlives lint](rust-lang#89970) * On 2021-12-29. [Parse and suggest moving where clauses after equals for type aliases](rust-lang#92118) * On 2022-01-15, [Ignore static lifetimes for GATs outlives lint](rust-lang#92865) * On 2022-02-08, [Don't constrain projection predicates with inference vars in GAT substs](rust-lang#92917) * On 2022-02-15, [Rework GAT where clause check](rust-lang#93820) * On 2022-02-19, [Only mark projection as ambiguous if GAT substs are constrained](rust-lang#93892) * On 2022-03-03, [Support GATs in Rustdoc](rust-lang#94009) * On 2022-03-06, [Change location of where clause on GATs](rust-lang#90076) * On 2022-05-04, [A shiny future with GATs blog post](https://jackh726.github.io/rust/2022/05/04/a-shiny-future-with-gats.html) * On 2022-05-04, [Stabilization PR](rust-lang#96709)

Stabilize generic associated types Closes #44265 r? `@nikomatsakis` # ⚡ Status of the discussion ⚡ * [x] There have been several serious concerns raised, [summarized here](rust-lang/rust#96709 (comment)). * [x] There has also been a [deep-dive comment](rust-lang/rust#96709 (comment)) explaining some of the "patterns of code" that are enabled by GATs, based on use-cases posted to this thread or on the tracking issue. * [x] We have modeled some aspects of GATs in [a-mir-formality](https://github.com/nikomatsakis/a-mir-formality) to give better confidence in how they will be resolved in the future. [You can read a write-up here](https://github.com/rust-lang/types-team/blob/master/minutes/2022-07-08-implied-bounds-and-wf-checking.md). * [x] The major points of the discussion have been [summarized on the GAT initiative repository](https://rust-lang.github.io/generic-associated-types-initiative/mvp.html). * [x] [FCP has been proposed](rust-lang/rust#96709 (comment)) and we are awaiting final decisions and discussion amidst the relevant team members. # Stabilization proposal This PR proposes the stabilization of `#![feature(generic_associated_types)]`. While there a number of future additions to be made and bugs to be fixed (both discussed below), properly doing these will require significant language design and will ultimately likely be backwards-compatible. Given the overwhelming desire to have some form of generic associated types (GATs) available on stable and the stability of the "simple" uses, stabilizing the current subset of GAT features is almost certainly the correct next step. Tracking issue: #44265 Initiative: https://rust-lang.github.io/generic-associated-types-initiative/ RFC: https://github.com/rust-lang/rfcs/blob/master/text/1598-generic_associated_types.md Version: 1.65 (2022-08-22 => beta, 2022-11-03 => stable). ## Motivation There are a myriad of potential use cases for GATs. Stabilization unblocks probable future language features (e.g. async functions in traits), potential future standard library features (e.g. a `LendingIterator` or some form of `Iterator` with a lifetime generic), and a plethora of user use cases (some of which can be seen just by scrolling through the tracking issue and looking at all the issues linking to it). There are a myriad of potential use cases for GATs. First, there are many users that have chosen to not use GATs primarily because they are not stable (some of which can be seen just by scrolling through the tracking issue and looking at all the issues linking to it). Second, while language feature desugaring isn't *blocked* on stabilization, it gives more confidence on using the feature. Likewise, library features like `LendingIterator` are not necessarily blocked on stabilization to be implemented unstably; however few, if any, public-facing APIs actually use unstable features. This feature has a long history of design, discussion, and developement - the RFC was first introduced roughly 6 years ago. While there are still a number of features left to implement and bugs left to fix, it's clear that it's unlikely those will have backwards-incompatibility concerns. Additionally, the bugs that do exist do not strongly impede the most-common use cases. ## What is stabilized The primary language feature stabilized here is the ability to have generics on associated types, as so. Additionally, where clauses on associated types will now be accepted, regardless if the associated type is generic or not. ```rust trait ATraitWithGATs { type Assoc<'a, T> where T: 'a; } trait ATraitWithoutGATs<'a, T> { type Assoc where T: 'a; } ``` When adding an impl for a trait with generic associated types, the generics for the associated type are copied as well. Note that where clauses are allowed both after the specified type and before the equals sign; however, the latter is a warn-by-default deprecation. ```rust struct X; struct Y; impl ATraitWithGATs for X { type Assoc<'a, T> = &'a T where T: 'a; } impl ATraitWithGATs for Y { type Assoc<'a, T> where T: 'a = &'a T; } ``` To use a GAT in a function, generics are specified on the associated type, as if it was a struct or enum. GATs can also be specified in trait bounds: ```rust fn accepts_gat<'a, T>(t: &'a T) -> T::Assoc<'a, T> where for<'x> T: ATraitWithGATs<Assoc<'a, T> = &'a T> { ... } ``` GATs can also appear in trait methods. However, depending on how they are used, they may confer where clauses on the associated type definition. More information can be found [here](rust-lang/rust#87479). Briefly, where clauses are required when those bounds can be proven in the methods that *construct* the GAT or other associated types that use the GAT in the trait. This allows impls to have maximum flexibility in the types defined for the associated type. To take a relatively simple example: ```rust trait Iterable { type Item<'a>; type Iterator<'a>: Iterator<Item = Self::Item<'a>>; fn iter<'x>(&'x self) -> Self::Iterator<'x>; //^ We know that `Self: 'a` for `Iterator<'a>`, so we require that bound on `Iterator` // `Iterator` uses `Self::Item`, so we also require a `Self: 'a` on `Item` too } ``` A couple well-explained examples are available in a previous [blog post](https://blog.rust-lang.org/2021/08/03/GATs-stabilization-push.html). ## What isn't stabilized/implemented ### Universal type/const quantification Currently, you can write a bound like `X: for<'a> Trait<Assoc<'a> = &'a ()>`. However, you cannot currently write `for<T> X: Trait<Assoc<T> = T>` or `for<const N> X: Trait<Assoc<N> = [usize; N]>`. Here is an example where this is needed: ```rust trait Foo {} trait Trait { type Assoc<F: Foo>; } trait Trait2: Sized { fn foo<F: Foo, T: Trait<Assoc<F> = F>>(_t: T); } ``` In the above example, the *caller* must specify `F`, which is likely not what is desired. ### Object-safe GATs Unlike non-generic associated types, traits with GATs are not currently object-safe. In other words the following are not allowed: ```rust trait Trait { type Assoc<'a>; } fn foo(t: &dyn for<'a> Trait<Assoc<'a> = &'a ()>) {} //^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ not allowed let ty: Box<dyn for<'a> Trait<Assoc<'a> = &'a ()>>; //^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ not allowed ``` ### Higher-kinded types You cannot write currently (and there are no current plans to implement this): ```rust struct Struct<'a> {} fn foo(s: for<'a> Struct<'a>) {} ``` ## Tests There are many tests covering GATs that can be found in `src/test/ui/generic-associated-types`. Here, I'll list (in alphanumeric order) tests highlight some important behavior or contain important patterns. - `./parse/*`: Parsing of GATs in traits and impls, and the trait path with GATs - `./collections-project-default.rs`: Interaction with associated type defaults - `./collections.rs`: The `Collection` pattern - `./const-generics-gat-in-trait-return-type-*.rs`: Const parameters - `./constraint-assoc-type-suggestion.rs`: Emit correct syntax in suggestion - `./cross-crate-bounds.rs`: Ensure we handles bounds across crates the same - `./elided-in-expr-position.rs`: Disallow lifetime elision in return position - `./gat-in-trait-path-undeclared-lifetime.rs`: Ensure we error on undeclared lifetime in trait path - `./gat-in-trait-path.rs`: Base trait path case - `./gat-trait-path-generic-type-arg.rs`: Don't allow shadowing of parameters - `./gat-trait-path-parenthesised-args.rs`: Don't allow paranthesized args in trait path - `./generic-associated-types-where.rs`: Ensure that we require where clauses from trait to be met on impl - `./impl_bounds.rs`: Check that the bounds on GATs in an impl are checked - `./issue-76826.rs`: `Windows` pattern - `./issue-78113-lifetime-mismatch-dyn-trait-box.rs`: Implicit 'static diagnostics - `./issue-84931.rs`: Ensure that we have a where clause on GAT to ensure trait parameter lives long enough - `./issue-87258_a.rs`: Unconstrained opaque type with TAITs - `./issue-87429-2.rs`: Ensure we can use bound vars in the bounds - `./issue-87429-associated-type-default.rs`: Ensure bounds hold with associated type defaults, for both trait and impl - `./issue-87429-specialization.rs`: Check that bounds hold under specialization - `./issue-88595.rs`: Under the outlives lint, we require a bound for both trait and GAT lifetime when trait lifetime is used in function - `./issue-90014.rs`: Lifetime bounds are checked with TAITs - `./issue-91139.rs`: Under migrate mode, but not NLL, we don't capture implied bounds from HRTB lifetimes used in a function and GATs - `./issue-91762.rs`: We used to too eagerly pick param env candidates when normalizing with GATs. We now require explicit parameters specified. - `./issue-95305.rs`: Disallow lifetime elision in trait paths - `./iterable.rs`: `Iterable` pattern - `./method-unsatified-assoc-type-predicate.rs`: Print predicates with GATs correctly in method resolve error - `./missing_lifetime_const.rs`: Ensure we must specify lifetime args (not elidable) - `./missing-where-clause-on-trait.rs`: Ensure we don't allow stricter bounds on impl than trait - `./parameter_number_and_kind_impl.rs`: Ensure paramters on GAT in impl match GAT in trait - `./pointer_family.rs`: `PointerFamily` pattern - `./projection-bound-cycle.rs`: Don't allow invalid cycles to prove bounds - `./self-outlives-lint.rs`: Ensures that an e.g. `Self: 'a` is written on the traits GAT if that bound can be implied from the GAT usage in the trait - `./shadowing.rs`: Don't allow lifetime shadowing in params - `./streaming_iterator.rs`: `StreamingIterator`(`LendingIterator`) pattern - `./trait-objects.rs`: Disallow trait objects for traits with GATs - `./variance_constraints.rs`: Require that GAT substs be invariant ## Remaining bugs and open issues A full list of remaining open issues can be found at: https://github.com/rust-lang/rust/labels/F-generic_associated_types There are some `known-bug` tests in-tree at `src/test/ui/generic-associated-types/bugs`. Here I'll categorize most of those that GAT bugs (or involve a pattern found more with GATs), but not those that include GATs but not a GAT issue in and of itself. (I also won't include issues directly for things listed elsewhere here.) Using the concrete type of a GAT instead of the projection type can give errors, since lifetimes are chosen to be early-bound vs late-bound. - #85533 - #87803 In certain cases, we can run into cycle or overflow errors. This is more generally a problem with associated types. - #87755 - #87758 Bounds on an associatd type need to be proven by an impl, but where clauses need to be proven by the usage. This can lead to confusion when users write one when they mean the other. - #87831 - #90573 We sometimes can't normalize closure signatures fully. Really an asociated types issue, but might happen a bit more frequently with GATs, since more obvious place for HRTB lifetimes. - #88382 When calling a function, we assign types to parameters "too late", after we already try (and fail) to normalize projections. Another associated types issue that might pop up more with GATs. - #88460 - #96230 We don't fully have implied bounds for lifetimes appearing in GAT trait paths, which can lead to unconstrained type errors. - #88526 Suggestion for adding lifetime bounds can suggest unhelpful fixes (`T: 'a` instead of `Self: 'a`), but the next compiler error after making the suggested change is helpful. - #90816 - #92096 - #95268 We can end up requiring that `for<'a> I: 'a` when we really want `for<'a where I: 'a> I: 'a`. This can leave unhelpful errors than effectively can't be satisfied unless `I: 'static`. Requires bigger changes and not only GATs. - #91693 Unlike with non-generic associated types, we don't eagerly normalize with param env candidates. This is intended behavior (for now), to avoid accidentaly stabilizing picking arbitrary impls. - #91762 Some Iterator adapter patterns (namely `filter`) require Polonius or unsafe to work. - #92985 ## Potential Future work ### Universal type/const quantification No work has been done to implement this. There are also some questions around implied bounds. ### Object-safe GATs The intention is to make traits with GATs object-safe. There are some design work to be done around well-formedness rules and general implementation. ### GATified std lib types It would be helpful to either introduce new std lib traits (like `LendingIterator`) or to modify existing ones (adding a `'a` generic to `Iterator::Item`). There also a number of other candidates, like `Index`/`IndexMut` and `Fn`/`FnMut`/`FnOnce`. ### Reduce the need for `for<'a>` Seen [here](rust-lang/rfcs#1598 (comment)). One possible syntax: ```rust trait Iterable { type Iter<'a>: Iterator<Item = Self::Item<'a>>; } fn foo<T>() where T: Iterable, T::Item<let 'a>: Display { } //note the `let`! ``` ### Better implied bounds on higher-ranked things Currently if we have a `type Item<'a> where self: 'a`, and a `for<'a> T: Iterator<Item<'a> = &'a ()`, this requires `for<'a> Self: 'a`. Really, we want `for<'a where T: 'a> ...` There was some mentions of this all the back in the RFC thread [here](rust-lang/rfcs#1598 (comment)). ## Alternatives ### Make generics on associated type in bounds a binder Imagine the bound `for<'a> T: Trait<Item<'a>= &'a ()>`. It might be that `for<'a>` is "too large" and it should instead be `T: Trait<for<'a> Item<'a>= &'a ()>`. Brought up in RFC thread [here](rust-lang/rfcs#1598 (comment)) and in a few places since. Another related question: Is `for<'a>` the right syntax? Maybe `where<'a>`? Also originally found in RFC thread [here](rust-lang/rfcs#1598 (comment)). ### Stabilize lifetime GATs first This has been brought up a few times. The idea is to only allow GATs with lifetime parameters to in initial stabilization. This was probably most useful prior to actual implementation. At this point, lifetimes, types, and consts are all implemented and work. It feels like an arbitrary split without strong reason. ## History * On 2016-04-30, [RFC opened](rust-lang/rfcs#1598) * On 2017-09-02, RFC merged and [tracking issue opened](rust-lang/rust#44265) * On 2017-10-23, [Move Generics from MethodSig to TraitItem and ImplItem](rust-lang/rust#44766) * On 2017-12-01, [Generic Associated Types Parsing & Name Resolution](rust-lang/rust#45904) * On 2017-12-15, [https://github.com/rust-lang/rust/pull/46706](https://github.com/rust-lang/rust/pull/46706) * On 2018-04-23, [Feature gate where clauses on associated types](rust-lang/rust#49368) * On 2018-05-10, [Extend tests for RFC1598 (GAT)](rust-lang/rust#49423) * On 2018-05-24, [Finish implementing GATs (Chalk)](rust-lang/chalk#134) * On 2019-12-21, [Make GATs less ICE-prone](rust-lang/rust#67160) * On 2020-02-13, [fix lifetime shadowing check in GATs](rust-lang/rust#68938) * On 2020-06-20, [Projection bound validation](rust-lang/rust#72788) * On 2020-10-06, [Separate projection bounds and predicates](rust-lang/rust#73905) * On 2021-02-05, [Generic associated types in trait paths](rust-lang/rust#79554) * On 2021-02-06, [Trait objects do not work with generic associated types](rust-lang/rust#81823) * On 2021-04-28, [Make traits with GATs not object safe](rust-lang/rust#84622) * On 2021-05-11, [Improve diagnostics for GATs](rust-lang/rust#82272) * On 2021-07-16, [Make GATs no longer an incomplete feature](rust-lang/rust#84623) * On 2021-07-16, [Replace associated item bound vars with placeholders when projecting](rust-lang/rust#86993) * On 2021-07-26, [GATs: Decide whether to have defaults for `where Self: 'a`](rust-lang/rust#87479) * On 2021-08-25, [Normalize projections under binders](rust-lang/rust#85499) * On 2021-08-03, [The push for GATs stabilization](https://blog.rust-lang.org/2021/08/03/GATs-stabilization-push.html) * On 2021-08-12, [Detect stricter constraints on gats where clauses in impls vs trait](rust-lang/rust#88336) * On 2021-09-20, [Proposal: Change syntax of where clauses on type aliases](rust-lang/rust#89122) * On 2021-11-06, [Implementation of GATs outlives lint](rust-lang/rust#89970) * On 2021-12-29. [Parse and suggest moving where clauses after equals for type aliases](rust-lang/rust#92118) * On 2022-01-15, [Ignore static lifetimes for GATs outlives lint](rust-lang/rust#92865) * On 2022-02-08, [Don't constrain projection predicates with inference vars in GAT substs](rust-lang/rust#92917) * On 2022-02-15, [Rework GAT where clause check](rust-lang/rust#93820) * On 2022-02-19, [Only mark projection as ambiguous if GAT substs are constrained](rust-lang/rust#93892) * On 2022-03-03, [Support GATs in Rustdoc](rust-lang/rust#94009) * On 2022-03-06, [Change location of where clause on GATs](rust-lang/rust#90076) * On 2022-05-04, [A shiny future with GATs blog post](https://jackh726.github.io/rust/2022/05/04/a-shiny-future-with-gats.html) * On 2022-05-04, [Stabilization PR](rust-lang/rust#96709)

Broken due to rust-lang/rust#89970

Stabilize generic associated types Closes #44265 r? `@nikomatsakis` # ⚡ Status of the discussion ⚡ * [x] There have been several serious concerns raised, [summarized here](rust-lang/rust#96709 (comment)). * [x] There has also been a [deep-dive comment](rust-lang/rust#96709 (comment)) explaining some of the "patterns of code" that are enabled by GATs, based on use-cases posted to this thread or on the tracking issue. * [x] We have modeled some aspects of GATs in [a-mir-formality](https://github.com/nikomatsakis/a-mir-formality) to give better confidence in how they will be resolved in the future. [You can read a write-up here](https://github.com/rust-lang/types-team/blob/master/minutes/2022-07-08-implied-bounds-and-wf-checking.md). * [x] The major points of the discussion have been [summarized on the GAT initiative repository](https://rust-lang.github.io/generic-associated-types-initiative/mvp.html). * [x] [FCP has been proposed](rust-lang/rust#96709 (comment)) and we are awaiting final decisions and discussion amidst the relevant team members. # Stabilization proposal This PR proposes the stabilization of `#![feature(generic_associated_types)]`. While there a number of future additions to be made and bugs to be fixed (both discussed below), properly doing these will require significant language design and will ultimately likely be backwards-compatible. Given the overwhelming desire to have some form of generic associated types (GATs) available on stable and the stability of the "simple" uses, stabilizing the current subset of GAT features is almost certainly the correct next step. Tracking issue: #44265 Initiative: https://rust-lang.github.io/generic-associated-types-initiative/ RFC: https://github.com/rust-lang/rfcs/blob/master/text/1598-generic_associated_types.md Version: 1.65 (2022-08-22 => beta, 2022-11-03 => stable). ## Motivation There are a myriad of potential use cases for GATs. Stabilization unblocks probable future language features (e.g. async functions in traits), potential future standard library features (e.g. a `LendingIterator` or some form of `Iterator` with a lifetime generic), and a plethora of user use cases (some of which can be seen just by scrolling through the tracking issue and looking at all the issues linking to it). There are a myriad of potential use cases for GATs. First, there are many users that have chosen to not use GATs primarily because they are not stable (some of which can be seen just by scrolling through the tracking issue and looking at all the issues linking to it). Second, while language feature desugaring isn't *blocked* on stabilization, it gives more confidence on using the feature. Likewise, library features like `LendingIterator` are not necessarily blocked on stabilization to be implemented unstably; however few, if any, public-facing APIs actually use unstable features. This feature has a long history of design, discussion, and developement - the RFC was first introduced roughly 6 years ago. While there are still a number of features left to implement and bugs left to fix, it's clear that it's unlikely those will have backwards-incompatibility concerns. Additionally, the bugs that do exist do not strongly impede the most-common use cases. ## What is stabilized The primary language feature stabilized here is the ability to have generics on associated types, as so. Additionally, where clauses on associated types will now be accepted, regardless if the associated type is generic or not. ```rust trait ATraitWithGATs { type Assoc<'a, T> where T: 'a; } trait ATraitWithoutGATs<'a, T> { type Assoc where T: 'a; } ``` When adding an impl for a trait with generic associated types, the generics for the associated type are copied as well. Note that where clauses are allowed both after the specified type and before the equals sign; however, the latter is a warn-by-default deprecation. ```rust struct X; struct Y; impl ATraitWithGATs for X { type Assoc<'a, T> = &'a T where T: 'a; } impl ATraitWithGATs for Y { type Assoc<'a, T> where T: 'a = &'a T; } ``` To use a GAT in a function, generics are specified on the associated type, as if it was a struct or enum. GATs can also be specified in trait bounds: ```rust fn accepts_gat<'a, T>(t: &'a T) -> T::Assoc<'a, T> where for<'x> T: ATraitWithGATs<Assoc<'a, T> = &'a T> { ... } ``` GATs can also appear in trait methods. However, depending on how they are used, they may confer where clauses on the associated type definition. More information can be found [here](rust-lang/rust#87479). Briefly, where clauses are required when those bounds can be proven in the methods that *construct* the GAT or other associated types that use the GAT in the trait. This allows impls to have maximum flexibility in the types defined for the associated type. To take a relatively simple example: ```rust trait Iterable { type Item<'a>; type Iterator<'a>: Iterator<Item = Self::Item<'a>>; fn iter<'x>(&'x self) -> Self::Iterator<'x>; //^ We know that `Self: 'a` for `Iterator<'a>`, so we require that bound on `Iterator` // `Iterator` uses `Self::Item`, so we also require a `Self: 'a` on `Item` too } ``` A couple well-explained examples are available in a previous [blog post](https://blog.rust-lang.org/2021/08/03/GATs-stabilization-push.html). ## What isn't stabilized/implemented ### Universal type/const quantification Currently, you can write a bound like `X: for<'a> Trait<Assoc<'a> = &'a ()>`. However, you cannot currently write `for<T> X: Trait<Assoc<T> = T>` or `for<const N> X: Trait<Assoc<N> = [usize; N]>`. Here is an example where this is needed: ```rust trait Foo {} trait Trait { type Assoc<F: Foo>; } trait Trait2: Sized { fn foo<F: Foo, T: Trait<Assoc<F> = F>>(_t: T); } ``` In the above example, the *caller* must specify `F`, which is likely not what is desired. ### Object-safe GATs Unlike non-generic associated types, traits with GATs are not currently object-safe. In other words the following are not allowed: ```rust trait Trait { type Assoc<'a>; } fn foo(t: &dyn for<'a> Trait<Assoc<'a> = &'a ()>) {} //^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ not allowed let ty: Box<dyn for<'a> Trait<Assoc<'a> = &'a ()>>; //^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ not allowed ``` ### Higher-kinded types You cannot write currently (and there are no current plans to implement this): ```rust struct Struct<'a> {} fn foo(s: for<'a> Struct<'a>) {} ``` ## Tests There are many tests covering GATs that can be found in `src/test/ui/generic-associated-types`. Here, I'll list (in alphanumeric order) tests highlight some important behavior or contain important patterns. - `./parse/*`: Parsing of GATs in traits and impls, and the trait path with GATs - `./collections-project-default.rs`: Interaction with associated type defaults - `./collections.rs`: The `Collection` pattern - `./const-generics-gat-in-trait-return-type-*.rs`: Const parameters - `./constraint-assoc-type-suggestion.rs`: Emit correct syntax in suggestion - `./cross-crate-bounds.rs`: Ensure we handles bounds across crates the same - `./elided-in-expr-position.rs`: Disallow lifetime elision in return position - `./gat-in-trait-path-undeclared-lifetime.rs`: Ensure we error on undeclared lifetime in trait path - `./gat-in-trait-path.rs`: Base trait path case - `./gat-trait-path-generic-type-arg.rs`: Don't allow shadowing of parameters - `./gat-trait-path-parenthesised-args.rs`: Don't allow paranthesized args in trait path - `./generic-associated-types-where.rs`: Ensure that we require where clauses from trait to be met on impl - `./impl_bounds.rs`: Check that the bounds on GATs in an impl are checked - `./issue-76826.rs`: `Windows` pattern - `./issue-78113-lifetime-mismatch-dyn-trait-box.rs`: Implicit 'static diagnostics - `./issue-84931.rs`: Ensure that we have a where clause on GAT to ensure trait parameter lives long enough - `./issue-87258_a.rs`: Unconstrained opaque type with TAITs - `./issue-87429-2.rs`: Ensure we can use bound vars in the bounds - `./issue-87429-associated-type-default.rs`: Ensure bounds hold with associated type defaults, for both trait and impl - `./issue-87429-specialization.rs`: Check that bounds hold under specialization - `./issue-88595.rs`: Under the outlives lint, we require a bound for both trait and GAT lifetime when trait lifetime is used in function - `./issue-90014.rs`: Lifetime bounds are checked with TAITs - `./issue-91139.rs`: Under migrate mode, but not NLL, we don't capture implied bounds from HRTB lifetimes used in a function and GATs - `./issue-91762.rs`: We used to too eagerly pick param env candidates when normalizing with GATs. We now require explicit parameters specified. - `./issue-95305.rs`: Disallow lifetime elision in trait paths - `./iterable.rs`: `Iterable` pattern - `./method-unsatified-assoc-type-predicate.rs`: Print predicates with GATs correctly in method resolve error - `./missing_lifetime_const.rs`: Ensure we must specify lifetime args (not elidable) - `./missing-where-clause-on-trait.rs`: Ensure we don't allow stricter bounds on impl than trait - `./parameter_number_and_kind_impl.rs`: Ensure paramters on GAT in impl match GAT in trait - `./pointer_family.rs`: `PointerFamily` pattern - `./projection-bound-cycle.rs`: Don't allow invalid cycles to prove bounds - `./self-outlives-lint.rs`: Ensures that an e.g. `Self: 'a` is written on the traits GAT if that bound can be implied from the GAT usage in the trait - `./shadowing.rs`: Don't allow lifetime shadowing in params - `./streaming_iterator.rs`: `StreamingIterator`(`LendingIterator`) pattern - `./trait-objects.rs`: Disallow trait objects for traits with GATs - `./variance_constraints.rs`: Require that GAT substs be invariant ## Remaining bugs and open issues A full list of remaining open issues can be found at: https://github.com/rust-lang/rust/labels/F-generic_associated_types There are some `known-bug` tests in-tree at `src/test/ui/generic-associated-types/bugs`. Here I'll categorize most of those that GAT bugs (or involve a pattern found more with GATs), but not those that include GATs but not a GAT issue in and of itself. (I also won't include issues directly for things listed elsewhere here.) Using the concrete type of a GAT instead of the projection type can give errors, since lifetimes are chosen to be early-bound vs late-bound. - #85533 - #87803 In certain cases, we can run into cycle or overflow errors. This is more generally a problem with associated types. - #87755 - #87758 Bounds on an associatd type need to be proven by an impl, but where clauses need to be proven by the usage. This can lead to confusion when users write one when they mean the other. - #87831 - #90573 We sometimes can't normalize closure signatures fully. Really an asociated types issue, but might happen a bit more frequently with GATs, since more obvious place for HRTB lifetimes. - #88382 When calling a function, we assign types to parameters "too late", after we already try (and fail) to normalize projections. Another associated types issue that might pop up more with GATs. - #88460 - #96230 We don't fully have implied bounds for lifetimes appearing in GAT trait paths, which can lead to unconstrained type errors. - #88526 Suggestion for adding lifetime bounds can suggest unhelpful fixes (`T: 'a` instead of `Self: 'a`), but the next compiler error after making the suggested change is helpful. - #90816 - #92096 - #95268 We can end up requiring that `for<'a> I: 'a` when we really want `for<'a where I: 'a> I: 'a`. This can leave unhelpful errors than effectively can't be satisfied unless `I: 'static`. Requires bigger changes and not only GATs. - #91693 Unlike with non-generic associated types, we don't eagerly normalize with param env candidates. This is intended behavior (for now), to avoid accidentaly stabilizing picking arbitrary impls. - #91762 Some Iterator adapter patterns (namely `filter`) require Polonius or unsafe to work. - #92985 ## Potential Future work ### Universal type/const quantification No work has been done to implement this. There are also some questions around implied bounds. ### Object-safe GATs The intention is to make traits with GATs object-safe. There are some design work to be done around well-formedness rules and general implementation. ### GATified std lib types It would be helpful to either introduce new std lib traits (like `LendingIterator`) or to modify existing ones (adding a `'a` generic to `Iterator::Item`). There also a number of other candidates, like `Index`/`IndexMut` and `Fn`/`FnMut`/`FnOnce`. ### Reduce the need for `for<'a>` Seen [here](rust-lang/rfcs#1598 (comment)). One possible syntax: ```rust trait Iterable { type Iter<'a>: Iterator<Item = Self::Item<'a>>; } fn foo<T>() where T: Iterable, T::Item<let 'a>: Display { } //note the `let`! ``` ### Better implied bounds on higher-ranked things Currently if we have a `type Item<'a> where self: 'a`, and a `for<'a> T: Iterator<Item<'a> = &'a ()`, this requires `for<'a> Self: 'a`. Really, we want `for<'a where T: 'a> ...` There was some mentions of this all the back in the RFC thread [here](rust-lang/rfcs#1598 (comment)). ## Alternatives ### Make generics on associated type in bounds a binder Imagine the bound `for<'a> T: Trait<Item<'a>= &'a ()>`. It might be that `for<'a>` is "too large" and it should instead be `T: Trait<for<'a> Item<'a>= &'a ()>`. Brought up in RFC thread [here](rust-lang/rfcs#1598 (comment)) and in a few places since. Another related question: Is `for<'a>` the right syntax? Maybe `where<'a>`? Also originally found in RFC thread [here](rust-lang/rfcs#1598 (comment)). ### Stabilize lifetime GATs first This has been brought up a few times. The idea is to only allow GATs with lifetime parameters to in initial stabilization. This was probably most useful prior to actual implementation. At this point, lifetimes, types, and consts are all implemented and work. It feels like an arbitrary split without strong reason. ## History * On 2016-04-30, [RFC opened](rust-lang/rfcs#1598) * On 2017-09-02, RFC merged and [tracking issue opened](rust-lang/rust#44265) * On 2017-10-23, [Move Generics from MethodSig to TraitItem and ImplItem](rust-lang/rust#44766) * On 2017-12-01, [Generic Associated Types Parsing & Name Resolution](rust-lang/rust#45904) * On 2017-12-15, [https://github.com/rust-lang/rust/pull/46706](https://github.com/rust-lang/rust/pull/46706) * On 2018-04-23, [Feature gate where clauses on associated types](rust-lang/rust#49368) * On 2018-05-10, [Extend tests for RFC1598 (GAT)](rust-lang/rust#49423) * On 2018-05-24, [Finish implementing GATs (Chalk)](rust-lang/chalk#134) * On 2019-12-21, [Make GATs less ICE-prone](rust-lang/rust#67160) * On 2020-02-13, [fix lifetime shadowing check in GATs](rust-lang/rust#68938) * On 2020-06-20, [Projection bound validation](rust-lang/rust#72788) * On 2020-10-06, [Separate projection bounds and predicates](rust-lang/rust#73905) * On 2021-02-05, [Generic associated types in trait paths](rust-lang/rust#79554) * On 2021-02-06, [Trait objects do not work with generic associated types](rust-lang/rust#81823) * On 2021-04-28, [Make traits with GATs not object safe](rust-lang/rust#84622) * On 2021-05-11, [Improve diagnostics for GATs](rust-lang/rust#82272) * On 2021-07-16, [Make GATs no longer an incomplete feature](rust-lang/rust#84623) * On 2021-07-16, [Replace associated item bound vars with placeholders when projecting](rust-lang/rust#86993) * On 2021-07-26, [GATs: Decide whether to have defaults for `where Self: 'a`](rust-lang/rust#87479) * On 2021-08-25, [Normalize projections under binders](rust-lang/rust#85499) * On 2021-08-03, [The push for GATs stabilization](https://blog.rust-lang.org/2021/08/03/GATs-stabilization-push.html) * On 2021-08-12, [Detect stricter constraints on gats where clauses in impls vs trait](rust-lang/rust#88336) * On 2021-09-20, [Proposal: Change syntax of where clauses on type aliases](rust-lang/rust#89122) * On 2021-11-06, [Implementation of GATs outlives lint](rust-lang/rust#89970) * On 2021-12-29. [Parse and suggest moving where clauses after equals for type aliases](rust-lang/rust#92118) * On 2022-01-15, [Ignore static lifetimes for GATs outlives lint](rust-lang/rust#92865) * On 2022-02-08, [Don't constrain projection predicates with inference vars in GAT substs](rust-lang/rust#92917) * On 2022-02-15, [Rework GAT where clause check](rust-lang/rust#93820) * On 2022-02-19, [Only mark projection as ambiguous if GAT substs are constrained](rust-lang/rust#93892) * On 2022-03-03, [Support GATs in Rustdoc](rust-lang/rust#94009) * On 2022-03-06, [Change location of where clause on GATs](rust-lang/rust#90076) * On 2022-05-04, [A shiny future with GATs blog post](https://jackh726.github.io/rust/2022/05/04/a-shiny-future-with-gats.html) * On 2022-05-04, [Stabilization PR](rust-lang/rust#96709)

jackh726 added 5 commits October 16, 2021 19:04

Error initial pass

0bc340f

Some cleanup

a8c44d3

Change outlives clause checking algorithm

82148cd

Better error

e391796

Edit GATs tests to apply lint

c2da210

rust-highfive assigned nikomatsakis Oct 17, 2021

rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Oct 17, 2021

This comment has been minimized.

Sign in to view

Don't just check params

f9e14af

jackh726 force-pushed the gats_diagnostics branch from 29acb05 to f9e14af Compare October 18, 2021 14:13

nikomatsakis requested changes Oct 25, 2021

View reviewed changes

nikomatsakis mentioned this pull request Oct 25, 2021

GATs: Decide whether to have defaults for where Self: 'a #87479

Open

apiraino added the T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. label Oct 28, 2021

jackh726 added 3 commits October 31, 2021 21:36

Review comments and more tests

b84044a

Add lint for region pairs too

18421b1

Move outlives checking to separate functions

ef5e31a

jackh726 commented Nov 1, 2021

View reviewed changes

This comment has been minimized.

Sign in to view

nikomatsakis reviewed Nov 5, 2021

View reviewed changes

Review comments

b6edcbd

bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Nov 6, 2021

bors added the merged-by-bors This PR was explicitly merged by bors. label Nov 6, 2021

bors merged commit 9d39f6a into rust-lang:master Nov 6, 2021

rustbot added this to the 1.58.0 milestone Nov 6, 2021

jackh726 deleted the gats_diagnostics branch November 6, 2021 13:27

JanBeh mentioned this pull request Nov 8, 2021

Problem with GATs, async, and Send-bounds #90696

Open

MingweiSamuel added a commit to hydro-project/hydro that referenced this pull request Nov 8, 2021

Fix the spinach GATs build

9cb62c0

Broken due to rust-lang/rust#89970

This comment has been minimized.

Sign in to view

This was referenced Nov 11, 2021

Not compiling after adding the GAT Self: 'a bounds #90808

Closed

Wrong where Self: 'a GAT bound suggested #90816

Open

Reproduce gat issue vandenheuvel/relp#38

Merged

i64 mentioned this pull request Nov 17, 2021

Generates invalid code after rust-lang/rust#89970 4lDO2/real-async-trait-rs#4

Closed

ilslv mentioned this pull request Nov 19, 2021

Lifetime in GAT must outlive trait parameters #91036

Closed

dhardy mentioned this pull request Nov 29, 2021

GATs: repeating not-locally-required bounds on impls? #91348

Closed

jackh726 restored the gats_diagnostics branch March 12, 2022 18:30

jackh726 deleted the gats_diagnostics branch March 12, 2022 18:34

jackh726 restored the gats_diagnostics branch March 12, 2022 18:42

jackh726 deleted the gats_diagnostics branch March 12, 2022 18:45

jackh726 mentioned this pull request May 4, 2022

Stabilize generic associated types #96709

Merged

5 tasks

nickjiang2378 pushed a commit to nickjiang2378/hydroflow that referenced this pull request Jan 24, 2024

Fix the spinach GATs build

049f4d9

Broken due to rust-lang/rust#89970

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Implementation of GATs outlives lint #89970

Implementation of GATs outlives lint #89970

jackh726 commented Oct 17, 2021

This comment has been minimized.

nikomatsakis left a comment

nikomatsakis Oct 25, 2021

nikomatsakis Oct 25, 2021

nikomatsakis Oct 25, 2021

nikomatsakis commented Oct 25, 2021

jackh726 Nov 1, 2021

jackh726 Nov 1, 2021

jackh726 commented Nov 1, 2021

This comment has been minimized.

nikomatsakis left a comment

nikomatsakis Nov 5, 2021

jackh726 commented Nov 6, 2021

bors commented Nov 6, 2021

bors commented Nov 6, 2021

bors commented Nov 6, 2021

rust-timer commented Nov 6, 2021

This comment has been minimized.

jackh726 commented Nov 8, 2021

This comment has been minimized.

This comment has been minimized.

		/// Require that the user writes as where clauses on GATs the implicit
		/// outlives bounds involving trait parameters in trait functions and

Implementation of GATs outlives lint #89970

Implementation of GATs outlives lint #89970

Conversation

jackh726 commented Oct 17, 2021

Intuitive Explanation (Attempt)

Implementation Algorithm

Follow-up questions

This comment has been minimized.

nikomatsakis left a comment

Choose a reason for hiding this comment

nikomatsakis Oct 25, 2021

Choose a reason for hiding this comment

nikomatsakis Oct 25, 2021

Choose a reason for hiding this comment

nikomatsakis Oct 25, 2021

Choose a reason for hiding this comment

nikomatsakis commented Oct 25, 2021

jackh726 Nov 1, 2021

Choose a reason for hiding this comment

jackh726 Nov 1, 2021

Choose a reason for hiding this comment

jackh726 commented Nov 1, 2021

This comment has been minimized.

nikomatsakis left a comment

Choose a reason for hiding this comment

nikomatsakis Nov 5, 2021

Choose a reason for hiding this comment

jackh726 commented Nov 6, 2021

bors commented Nov 6, 2021

bors commented Nov 6, 2021

bors commented Nov 6, 2021

rust-timer commented Nov 6, 2021

This comment has been minimized.

jackh726 commented Nov 8, 2021

This comment has been minimized.

This comment has been minimized.