Only mark projection as ambiguous if GAT substs are constrained by compiler-errors · Pull Request #93892 · rust-lang/rust (original) (raw)

compiler-errors

@rustbot rustbot added the T-compiler

Relevant to the compiler team, which will review and decide on the PR/issue.

label

Feb 11, 2022

@compiler-errors

compiler-errors

jackh726

@bors 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

Feb 14, 2022

marmeladema

@compiler-errors

jackh726

bors added a commit to rust-lang-ci/rust that referenced this pull request

Feb 19, 2022

@bors

…askrgr

Rollup of 10 pull requests

Successful merges:

Failed merges:

r? @ghost @rustbot modify labels: rollup

MingweiSamuel added a commit to MingweiSamuel/hydroflow that referenced this pull request

Feb 23, 2022

@MingweiSamuel

bors added a commit to rust-lang-ci/rust that referenced this pull request

Sep 13, 2022

@bors

…er-errors

Stabilize generic associated types

Closes rust-lang#44265

r? @nikomatsakis

⚡ Status of the discussion ⚡

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.

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.

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:

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. 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:

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.

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:

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:

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):

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.

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.

In certain cases, we can run into cycle or overflow errors. This is more generally a problem with associated types.

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.

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.

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.

We don't fully have implied bounds for lifetimes appearing in GAT trait paths, which can lead to unconstrained type errors.

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.

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.

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.

Some Iterator adapter patterns (namely filter) require Polonius or unsafe to work.

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:

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

calebcartwright pushed a commit to calebcartwright/rustfmt that referenced this pull request

Jan 24, 2023

@bors

Stabilize generic associated types

Closes #44265

r? @nikomatsakis

⚡ Status of the discussion ⚡

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.

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.

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:

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. 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:

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.

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:

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:

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):

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.

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.

In certain cases, we can run into cycle or overflow errors. This is more generally a problem with associated types.

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.

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.

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.

We don't fully have implied bounds for lifetimes appearing in GAT trait paths, which can lead to unconstrained type errors.

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.

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.

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.

Some Iterator adapter patterns (namely filter) require Polonius or unsafe to work.

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:

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

RalfJung pushed a commit to RalfJung/rust-analyzer that referenced this pull request

Apr 20, 2024

@bors

Stabilize generic associated types

Closes #44265

r? @nikomatsakis

⚡ Status of the discussion ⚡

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.

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.

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:

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. 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:

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.

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:

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:

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):

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.

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.

In certain cases, we can run into cycle or overflow errors. This is more generally a problem with associated types.

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.

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.

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.

We don't fully have implied bounds for lifetimes appearing in GAT trait paths, which can lead to unconstrained type errors.

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.

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.

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.

Some Iterator adapter patterns (namely filter) require Polonius or unsafe to work.

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:

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

RalfJung pushed a commit to RalfJung/rust-analyzer that referenced this pull request

Apr 27, 2024

@bors

Stabilize generic associated types

Closes #44265

r? @nikomatsakis

⚡ Status of the discussion ⚡

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.

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.

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:

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. 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:

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.

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:

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:

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):

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.

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.

In certain cases, we can run into cycle or overflow errors. This is more generally a problem with associated types.

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.

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.

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.

We don't fully have implied bounds for lifetimes appearing in GAT trait paths, which can lead to unconstrained type errors.

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.

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.

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.

Some Iterator adapter patterns (namely filter) require Polonius or unsafe to work.

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:

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

jieyouxu added a commit to jieyouxu/rust that referenced this pull request

May 18, 2024

@jieyouxu

Only make GAT ambiguous in match_projection_projections considering shallow resolvability

In rust-lang#123537, I tweaked the hack from rust-lang#93892 to use resolve_vars_if_possible instead of shallow_resolve. This considers more inference guidance ambiguous. This resulted in crater regressions in rust-lang#125196.

I've effectively reverted the change to the old behavior. That being said, I don't like this behavior, but I'd rather keep it for now since rust-lang#123537 was not meant to make any behavioral changes. See the attached example.

This also affects the new solver, for the record, which doesn't have any rules about not guiding inference from param-env candidates which may constrain GAT args as a side-effect.

r? @lcnr or @jackh726

rust-timer added a commit to rust-lang-ci/rust that referenced this pull request

May 18, 2024

@rust-timer

Rollup merge of rust-lang#125214 - compiler-errors:gat-guide, r=lcnr

Only make GAT ambiguous in match_projection_projections considering shallow resolvability

In rust-lang#123537, I tweaked the hack from rust-lang#93892 to use resolve_vars_if_possible instead of shallow_resolve. This considers more inference guidance ambiguous. This resulted in crater regressions in rust-lang#125196.

I've effectively reverted the change to the old behavior. That being said, I don't like this behavior, but I'd rather keep it for now since rust-lang#123537 was not meant to make any behavioral changes. See the attached example.

This also affects the new solver, for the record, which doesn't have any rules about not guiding inference from param-env candidates which may constrain GAT args as a side-effect.

r? @lcnr or @jackh726