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鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

馃敩 Tracking issue for generic associated types (GAT) #44265

Closed
25 of 28 tasks
Tracked by #1
withoutboats opened this issue Sep 2, 2017 · 143 comments 路 Fixed by #96709
Closed
25 of 28 tasks
Tracked by #1

馃敩 Tracking issue for generic associated types (GAT) #44265

withoutboats opened this issue Sep 2, 2017 · 143 comments 路 Fixed by #96709
Labels
A-associated-items Area: Associated items such as associated types and consts. A-traits Area: Trait system A-typesystem Area: The type system B-RFC-approved Approved by a merged RFC but not yet implemented. B-unstable Implemented in the nightly compiler and unstable. C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. F-generic_associated_types `#![feature(generic_associated_types)]` a.k.a. GATs requires-nightly This issue requires a nightly compiler in some way. S-tracking-ready-to-stabilize This is ready to stabilize; it may need a stabilization report and a PR S-types-tracked Status: Being actively tracked by the types team T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-lang Relevant to the language team, which will review and decide on the PR/issue. T-types Relevant to the types team, which will review and decide on the PR/issue.

Comments

@withoutboats
Copy link
Contributor

withoutboats commented Sep 2, 2017

This is a tracking issue for generic associated types (rust-lang/rfcs#1598)

Repository

Unresolved questions:

Blocking bugs

See also the GATs-blocking tag (the list below should be a superset of that, but its good to double-check).

Postponed work

@withoutboats withoutboats added A-associated-items Area: Associated items such as associated types and consts. A-traits Area: Trait system A-typesystem Area: The type system B-RFC-approved Approved by a merged RFC but not yet implemented. B-unstable Implemented in the nightly compiler and unstable. C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. T-lang Relevant to the language team, which will review and decide on the PR/issue. labels Sep 2, 2017
@nikomatsakis nikomatsakis added WG-traits Working group: Traits, https://internals.rust-lang.org/t/announcing-traits-working-group/6804 E-needs-mentor T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Sep 15, 2017
@nikomatsakis
Copy link
Contributor

nikomatsakis commented Sep 20, 2017

Here is a kind of implementation plan I will endeavor to keep updated.

  • Step one: add support into the AST and pretty-printing
    • Probably the first step is to start parsing the new forms and to add support for them to the AST.
    • See this comment for more detailed thoughts here.
    • We should be able to write some parsing-only tests and also test the pretty-printer hir
    • When we get to HIR lowering, we can error out if any GAT are present
    • We can also do the feature gate then
  • More to come

@nikomatsakis nikomatsakis added E-mentor Call for participation: This issue has a mentor. Use RustcContributor::new on Zulip for discussion. and removed E-needs-mentor labels Sep 20, 2017
@nikomatsakis nikomatsakis changed the title Tracking issue for generic associated types Tracking issue for generic associated types (GAT) Sep 21, 2017
@nikomatsakis
Copy link
Contributor

Let me start by writing about the AST in more detail. First let's discuss how it works today:

A type Foo: Bar [= Baz]; item in a trait definition is defined by this AST variant. That includes the bounds (Bar) and the (optional) default value Baz. The name is defined in the TraitItem struct.

A type Foo = Bar; item in a trait impl is defined by this AST variant -- that only includes the type Bar, because the Foo etc is defined in the ImplItem struct.

Methods are an interesting case because they can already be made generic. Those generic parameters are declared in the field Generics of the MethodSig structure. This is an instance of the Generics struct.

My take is that the best thing to do would be to "lift" Generics out from methods into the TraitItem (and ImplItem) so that it applies equally to all forms of trait and impl items. For now, we will not support generic constants, I guess, but honestly they probably just fall out from the work we are doing in any case, so they would be a small extension. I think the work will go better if we just plan for them now.

Perhaps a decent first PR would be to just do that change, keeping all other existing functionality the same. That is, we would more Generics into TraitItem (and ImplItem) and out of MethodSig. We would supply an empty Generics for non-methods. We would work through the existing code, plumbing the generics along as needed to make it work.

@sunjay
Copy link
Member

sunjay commented Sep 21, 2017

@nikomatsakis Cool! Thank you so much! I started experimenting with this last night and I'm proud to say that I found the same places you pointed to in your comment about the AST. 馃槃 (Given that this was my first time in rustc, I count that as an accomplishment!)

I didn't think to lift generics into TraitItem. My approach was to put Generics into TraitItemKind::Type since that's where the type declaration is stored already. Your approach makes sense too so I'll work on implementing that. Since I am still completely new to this codebase, I'm interested to know what the pitfalls of my approach would be if it were used over the one you suggested. Could you give me some insight into your thought process? 馃槂

Here's the change I would have made:

pub enum TraitItemKind {
    // Generics aren't supported here yet
    Const(P<Ty>, Option<P<Expr>>),
    // `Generics` is already a field in `MethodSig`
    Method(MethodSig, Option<P<Block>>),
    // Added `Generics` here:
    Type(Generics, TyParamBounds, Option<P<Ty>>),
    Macro(Mac),
}

Edit: Answer by nikomatsakis on Gitter

regarding the pitfalls of putting them in type
I think that could work too
the reason that I was reluctant to do that
is that we really want to do the same things (in theory, at least) for methods and types
and -- as I said -- in principle I see no reason we couldn't do the same things for constants
I think if you just move the Generics to the type variant
that would probably work ok, but if you look about, right now we often have to do "one thing for types/consts, one thing for methods" precisely because they are different
so I suspect the code will just get more uniform
I'm not really sure how it will go to be honest =) -- it might be a pain
but a lot of times having things be more generic than they have to be isn't so bad, because you can insert span_bug! calls in the impossible cases for now (and later we come aoround and patch them up)

@nikomatsakis
Copy link
Contributor

All right! Next step is to extend the parser. Here are a few tips. Let's start with trait items.

This routine parses trait items. We want to extend the case that handles associated types to also parse things like type Foo<....> = ...; (also maybe where-clauses). (The <...> is the "generics" that we just added to the AST.)

Currently it is using parse_ty_param, which basically parses something like T: Foo etc. We'll have to stop doing that, because the grammar for associated type declarations no longer matches that for type parameters. So we'll probably want to add something like parse_trait_item_assoc_ty. This can start as a kind of clone of parse_ty_param(), but then we'll want to modify it to invoke parse_generics() right about here. That routine will parse a generics declaration (<...>) if one is present, otherwise it just returns an empty generics. Then we want to add a call to parse where clauses right here -- you can model that on the call that occurs when parsing methods, note that the result is stored into the generics that we parsed earlier.

Once we've done that, we should be able to add some parsing tests. I would do that by making a directory like src/test/run-pass/rfc1598-generic-associated-types/ and adding files that you expect to successfully parse in there. Right now they won't work right, but that doesn't matter. Just add an empty main function. Then we can also add examples that should not parse into src/test/ui/rfc1598-generic-associated-types/ (see COMPILER_TESTS.md for directions on adding UI tests).

Something else -- we need to feature gate this work at this point, to avoid people using this stuff in stable builds. There are some instructions for adding a feature-gate here on forge (see the final section). We should add a visit_trait_item and visit_impl_item to the visitor in feature_gate.rs; if that item is not a method, but it has a non-empty generics, we can invoke gate_feature_post (example).

bors added a commit that referenced this issue Oct 24, 2017
Move Generics from MethodSig to TraitItem and ImplItem

As part of `rust-impl-period/WG-compiler-traits`, we want to "lift" `Generics` from `MethodSig` into `TraitItem` and `ImplItem`. This is in preparation for adding associated type generics. (#44265 (comment))

Currently this change is only made in the AST. In the future, it may also impact the HIR. (Still discussing)

To understand this PR, it's probably best to start from the changes to `ast.rs` and then work your way to the other files to understand the far reaching effects of this change.

r? @nikomatsakis
@nikomatsakis
Copy link
Contributor

nikomatsakis commented Nov 14, 2017

To setup name resolution, I think all we have to do is to get the proper "ribs" in place (the name resolution stuff organizes the sets of names that are in scope into ribs; each rib represents one binding level). e.g. for an impl:

impl<A,B> Foo<B> for Vec<A> {
   fn bar<T,U>(x: ...) { 
       for y in ... {
       }
   }
}

we would have the following ribs:

- <A,B> (from the impl)
   - <T,U> (from the `bar` method's generics)
      - `x` (from the parameter list)
          - `y` (from the let)

In general, modeling things on how methods work is not a bad idea. We might also do a bit of "future proofing" here, I suppose.

Here is the code that brings a method's type parameters into scope (this is for a method defined in a trait):

let type_parameters =
HasTypeParameters(&trait_item.generics,
MethodRibKind(!sig.decl.has_self()));

Whereas for a type defined in a trait, we are hardcoded to add an empty type parameter rib (NoTypeParameters):

TraitItemKind::Type(..) => {
this.with_type_parameter_rib(NoTypeParameters, |this| {
visit::walk_trait_item(this, trait_item)
});
}

Now that generics are in place on every trait/impl item, I think we probably want to remove the handling for type and extract the method handling so that it occurs at a higher level. For the items (e.g., const) where there are no generics, then the newly introduced rib ought to be empty and hence harmless (I hope).

Other points of interest:

You get the idea.

@petrochenkov -- sound about right?

@petrochenkov
Copy link
Contributor

@nikomatsakis

sound about right?

Everything looks correct.

bors added a commit that referenced this issue Dec 2, 2017
Generic Associated Types Parsing & Name Resolution

Hi!
This PR adds parsing for generic associated types! 馃帀 馃帀 馃帀

Tracking Issue: #44265

## Notes For Reviewers
* [x] I still need to add the stdout and stderr files to my ui tests. It takes me a *long* time to compile the compiler locally, so I'm going to add this as soon as possible in the next day or so.
* [ ] My current ui tests aren't very good or very thorough. I'm reusing the `parse_generics` and `parse_where_clause` methods from elsewhere in the parser, so my changes work without being particularly complex. I'm not sure if I should duplicate all of the generics test cases for generic associated types. It might actually be appropriate to duplicate everything here, since we don't want to rely on an implementation detail in case it changes in the future. If you think so too, I'll adapt all of the generics test cases into the generic associated types test cases.
* [ ] There is still more work required to make the run-pass tests pass here. In particular, we need to make the following errors disappear:
```
error[E0110]: lifetime parameters are not allowed on this type
  --> ./src/test/run-pass/rfc1598-generic-associated-types/streaming_iterator.rs:23:41
   |
23 |     bar: <T as StreamingIterator>::Item<'static>,
   |                                         ^^^^^^^ lifetime parameter not allowed on this type
```
```
error[E0261]: use of undeclared lifetime name `'a`
  --> ./src/test/run-pass/rfc1598-generic-associated-types/iterable.rs:15:47
   |
15 |     type Iter<'a>: Iterator<Item = Self::Item<'a>>;
   |                                               ^^ undeclared lifetime
```
There is a FIXME comment in streaming_iterator. If you uncomment that line, you get the following:
```
error: expected one of `!`, `+`, `,`, `::`, or `>`, found `=`
  --> ./src/test/run-pass/rfc1598-generic-associated-types/streaming_iterator.rs:29:45
   |
29 | fn foo<T: for<'a> StreamingIterator<Item<'a>=&'a [i32]>>(iter: T) { /* ... */ }
   |                                             ^ expected one of `!`, `+`, `,`, `::`, or `>` here
```

r? @nikomatsakis
@jackh726 jackh726 added S-tracking-ready-to-stabilize This is ready to stabilize; it may need a stabilization report and a PR T-types Relevant to the types team, which will review and decide on the PR/issue. S-types-tracked Status: Being actively tracked by the types team and removed S-tracking-needs-summary It's hard to tell what's been done and what hasn't! Someone should do some investigation. labels Jun 17, 2022
ryzhyk added a commit to gz/database-stream-processor that referenced this issue Jun 23, 2022
We should be able to switch back to stable once this is stabilized:
rust-lang/rust#44265
ryzhyk added a commit to gz/database-stream-processor that referenced this issue Jun 24, 2022
We should be able to switch back to stable once this is stabilized:
rust-lang/rust#44265
ryzhyk added a commit to vmware/database-stream-processor that referenced this issue Jun 24, 2022
We should be able to switch back to stable once this is stabilized:
rust-lang/rust#44265
ryzhyk added a commit to vmware/database-stream-processor that referenced this issue Jul 14, 2022
We continue the API cleanup (see #92).  Here we focus on operators that filter and
transform batches one record at a time (`map`, `filter`, `flat_map`),
etc.  One issue with these operators is that ergonomics requires
them to behave slightly differently for "non-indexed" batches like `OrdZSet`,
which conceptually represent multisets and "indexed" batches like
`OrdIndexedZSet`, which represent "weighted" key-value maps.  We expect
the `filter` operator to filter the former based on keys only and the
latter based on (key,value) pairs, i.e., we don't want the `filter`
operator to deal with a unit value `()` when filtering a Z-set.

To achieve this behavior we introduce a trait that abstracts a stream of
batches and defines an `Item` associated type, which can be `(K,V)`
for indexed batches and `K` for non-indexed batches.

The detailed design is described in the comment for the `FilterMap`
trait.

A few things to note:

- We ditch the forms of operators that take owned values.  This now feels
  like a premature optimization that does not even work since today we
  can only iterate over batches by reference.  We should be able to
  extend the trait and its implementations in the future to support
  this.

- We generalize `filter_map` to `flat_map`, which takes a closure that
  returns any iterable type.  The `filter_map` behavior is achieved by
  passing a closure that returns `Option<>`.

- We could split `FilterMap` into several traits.  I don't have a strong
  opinion either way.  Some advantages of having one trait: (1) it makes
  it easier for users and developers to explore these related methods
  in one place, (2) the user only needs to import one trait to access
  all its methods.  At least one disadvantage: I struggle to come up
  with an intuitive name for this trait. `FilterMap` does not feel
  ideal.

- One downside of the trait-based design is that we must implement it
  separately for each batch type.  This is ok so far, when we only have
  `OrdZSet` and `OrdIndexedZSet` and they require different
  implementations of the methods in question.  In the future we may need
  to find a way to generalize these implementations to avoid copying
  them.

- `trait FilterMap` relies on the unstable GAT feature:
   rust-lang/rust#44265
   which we already use in the cursor API.
@bors bors closed this as completed in 7098c18 Sep 13, 2022
danbev added a commit to danbev/eclipsecon-2022-hackathon that referenced this issue Oct 14, 2022
This commit updates the revision of embassy-time and embassy-sync
in infra/pre-provision to fix the following compilation error:

error[E0107]: this struct takes 1 generic argument but 2 generic arguments were supplied
  --> /.cargo/git/checkouts/btmesh-e14acedbce757b27/6840160/btmesh-device/src/lib.rs:34:27
   |
34 |     embassy_sync::signal::Signal<embassy_sync::blocking_mutex::raw::CriticalSectionRawMutex, T>;
   |                           ^^^^^^ expected 1 generic argument                                 - help: remove this generic argument
   |
note: struct defined here, with 1 generic parameter: `T`
  --> /.cargo/git/checkouts/embassy-9312dcb0ed774b29/3b58ac1/embassy-sync/src/signal.rs:31:12
   |
31 | pub struct Signal<T> {
   |            ^^^^^^ -

For more information about this error, try `rustc --explain E0107`.
error: could not compile `btmesh-device` due to previous error

The commit also adds a rust-toolchain.toml to configure nightly rustc as
currently there a number of compilation errors like the following two:

error[E0658]: generic associated types are unstable
   --> /.cargo/git/checkouts/embassy-9312dcb0ed774b29/b7d0944/embassy-sync/src/pipe.rs:450:9
    |
450 | /         type FlushFuture<'a> = impl Future<Output = Result<(), Self::Error>>
451 | |         where
452 | |             Self: 'a;
    | |_____________________^
    |
    = note: see issue #44265 <rust-lang/rust#44265> for more information
    = help: add `#![feature(generic_associated_types)]` to the crate attributes to enable

error[E0658]: where clauses on associated types are unstable
   --> /.cargo/git/checkouts/embassy-9312dcb0ed774b29/b7d0944/embassy-sync/src/pipe.rs:450:9
    |
450 | /         type FlushFuture<'a> = impl Future<Output = Result<(), Self::Error>>
451 | |         where
452 | |             Self: 'a;
    | |_____________________^
    |
    = note: see issue #44265 <rust-lang/rust#44265> for more information
    = help: add `#![feature(generic_associated_types)]` to the crate attributes to enable

   Compiling cargo_metadata v0.15.0
For more information about this error, try `rustc --explain E0658`.
error: could not compile `embassy-sync` due to 18 previous errors
warning: build failed, waiting for other jobs to finish...
punkeel added a commit to punkeel/capnproto-rust that referenced this issue Nov 23, 2022
The MSRV (minimum supported Rust version) is the earliest version capable of
building a project. In the case of the capnp crate, the MSRV is 1.65.0, due to
the use of GATs.

Having the MSRV in Cargo.toml helps display better error messages when the Rust
version is too old to build a project. eg:
> error: package `capnp v0.15.0 (/Users/maxime/Code/capnproto-rust/capnp)`
> cannot be built because it requires rustc 1.65.0 or newer, while the
> currently active rustc version is 1.64.0

Without it, the error messages are more confusing.
> error[E0658]: generic associated types are unstable
>   --> capnp/src/traits.rs:73:5
>    |
> 73 |     type Builder<'a>: FromStructBuilder<'a> + HasStructSize;
>   |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>   |
>   = note: see issue #44265 <rust-lang/rust#44265> for more information
punkeel added a commit to punkeel/capnproto-rust that referenced this issue Nov 23, 2022
The MSRV (minimum supported Rust version) is the earliest version capable of
building a project. In the case of the capnp crate, the MSRV is 1.65.0, due to
the use of GATs.

Having the MSRV in Cargo.toml helps display better error messages when the Rust
version is too old to build a project. eg:
> error: package `capnp v0.15.0 (/Users/maxime/Code/capnproto-rust/capnp)`
> cannot be built because it requires rustc 1.65.0 or newer, while the
> currently active rustc version is 1.64.0

Without it, the error messages are more confusing.
> error[E0658]: generic associated types are unstable
>   --> capnp/src/traits.rs:73:5
>    |
> 73 |     type Builder<'a>: FromStructBuilder<'a> + HasStructSize;
>   |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>   |
>   = note: see issue #44265 <rust-lang/rust#44265> for more information

Cargo.toml docs: https://doc.rust-lang.org/cargo/reference/manifest.html#the-rust-version-field
calebcartwright pushed a commit to calebcartwright/rustfmt that referenced this issue Jan 24, 2023
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, [rust-lang/rust#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)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-associated-items Area: Associated items such as associated types and consts. A-traits Area: Trait system A-typesystem Area: The type system B-RFC-approved Approved by a merged RFC but not yet implemented. B-unstable Implemented in the nightly compiler and unstable. C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. F-generic_associated_types `#![feature(generic_associated_types)]` a.k.a. GATs requires-nightly This issue requires a nightly compiler in some way. S-tracking-ready-to-stabilize This is ready to stabilize; it may need a stabilization report and a PR S-types-tracked Status: Being actively tracked by the types team T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-lang Relevant to the language team, which will review and decide on the PR/issue. T-types Relevant to the types team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging a pull request may close this issue.