Stabilize associated type bounds (RFC 2289)

[compiler-errors]

This PR stabilizes associated type bounds, which were laid out in RFC 2289. This gives us a shorthand to express nested type bounds that would otherwise need to be expressed with nested impl Trait or broken into several where clauses.

What are we stabilizing?

We're stabilizing the associated item bounds syntax, which allows us to put bounds in associated type position within other bounds, i.e. T: Trait<Assoc: Bounds...>. See RFC 2289 for motivation.

In all position, the associated type bound syntax expands into a set of two (or more) bounds, and never anything else (see "How does this differ[...]" section for more info).

Associated type bounds are stabilized in four positions:

• where clauses (and APIT) - This is equivalent to breaking up the bound into two (or more) where clauses. For example, where T: Trait<Assoc: Bound> is equivalent to where T: Trait, <T as Trait>::Assoc: Bound.
• Supertraits - Similar to above, trait CopyIterator: Iterator<Item: Copy> {}. This is almost equivalent to breaking up the bound into two (or more) where clauses; however, the bound on the associated item is implied whenever the trait is used. See Should associated type bounds on supertraits be implied? #112573/Make associated type bounds in supertrait position implied #112629.
• Associated type item bounds - This allows constraining the nested rigid projections that are associated with a trait's associated types. e.g. trait Trait { type Assoc: Trait2<Assoc2: Copy>; }.
• opaque item bounds (RPIT, TAIT) - This allows constraining associated types that are associated with the opaque without having to name the opaque. For example, impl Iterator<Item: Copy> defines an iterator whose item is Copy without having to actually name that item bound.

The latter three are not expressible in surface Rust (though for associated type item bounds, this will change in #120752, which I don't believe should block this PR), so this does represent a slight expansion of what can be expressed in trait bounds.

How does this differ from the RFC?

Compared to the RFC, the current implementation always desugars associated type bounds to sets of ty::Clauses internally. Specifically, it does not introduce a position-dependent desugaring as laid out in RFC 2289, and in particular:

• It does not desugar to anonymous associated items in associated type item bounds.
• It does not desugar to nested RPITs in RPIT bounds, nor nested TAITs in TAIT bounds.

This position-dependent desugaring laid out in the RFC existed simply to side-step limitations of the trait solver, which have mostly been fixed in #120584. The desugaring laid out in the RFC also added unnecessary complication to the design of the feature, and introduces its own limitations to, for example:

• Conditionally lowering to nested impl Trait in certain positions such as RPIT and TAIT means that we inherit the limitations of RPIT/TAIT, namely lack of support for higher-ranked opaque inference. See this code example: Collect relevant item bounds from trait clauses for nested rigid projections #120752 (comment).
• Introducing anonymous associated types makes traits no longer object safe, since anonymous associated types are not nameable, and all associated types must be named in dyn types.

This last point motivates why this PR is not stabilizing support for associated type bounds in dyn types, e.g, dyn Assoc<Item: Bound>. Why? Because dyn types need to have concrete types for all associated items, this would necessitate a distinct lowering for associated type bounds, which seems both complicated and unnecessary compared to just requiring the user to write impl Trait themselves. See #120719.

Implementation history:

Limited to the significant behavioral changes and fixes and relevant PRs, ping me if I left something out--

• Implementation of RFC 2289 (associated_type_bounds) #57428
• Ban associated type bounds in bad positions #108063
• Fix elaboration with associated type bounds #110512
• Make associated type bounds in supertrait position implied #112629
• Remove support for associated_type_bound nested in dyn types #120719
• For a rigid projection, recursively look at the self type's item bounds to fix the associated_type_bounds feature #120584

Closes #52662

[rustbot]

Some changes occurred in compiler/rustc_codegen_gcc

cc @antoyo, @GuillaumeGomez

[compiler-errors]

r? types
@rustbot label: I-lang-nominated

[joshtriplett]

Thank you to @compiler-errors and everyone else who has worked on this! It's wonderful seeing this brought to the point of stabilization. I know many people's fingers keep expecting that this already works. :)

@rfcbot merge

[rfcbot]

Team member @joshtriplett has proposed to merge this. The next step is review by the rest of the tagged team members:

• @BoxyUwU
• @aliemjay
• @compiler-errors
• @jackh726
• @joshtriplett
• @lcnr
• @nikomatsakis
• @oli-obk
• @pnkfelix
• @scottmcm
• @spastorino
• @tmandry

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
See this document for info about what commands tagged team members can give me.

[nikomatsakis]

@rfcbot reviewed

[jackh726]

For implementation history, its probably worth pointing out the PRs I made around the bound var refactoring. Its important in understanding how those are captured.

All in all though, I'm happy to see this stabilized. I also think its important to point out that other than in where clauses, you can't currently write these bounds, because they are more like the "ensures" clauses than the existing "where" clauses and thus have different effects on implied bounds.

[compiler-errors]

@jackh726:

For implementation history [...]

Feel free to edit and add more commits to the impl history section, since I don't know which ones you're talking about specifically. If they don't have to do with ATB specifically, maybe also leave a little note beside them that talks about how it impacts the impls?

I also think its important to point out that other than in where clauses, you can't currently write these bounds [...]

Yep. I pointed this out a bit in the document. See "The latter three are not expressible in surface Rust", "however, the bound on the associated item is implied whenever the trait is used". Perhaps ping me if you'd like to request additions to this stabilization doc to make this more clear.

[pnkfelix]

@rfcbot reviewed

[jdahlstrom]

[Associated type item bounds] are not expressible in surface Rust

I sort of had naively assumed that this would already work:

trait Foo {
    type Bar: Iterator 
    where 
        <Self::Bar as Iterator>::Item: Display;
}

but rather it just causes an overflow when evaluating an impl. Should it work and be equivalent to type Bar: Iterator<Item: Display>? It certainly feels a bit inconsistent if not.

[compiler-errors]

I sort of had naively assumed that this would already work [...]

Keep in mind that item bounds on associated types are not equivalent to where clauses in general, i.e.

trait Foo {
    type Assoc: Iterator;
}

// is not:

trait Foo {
    type Assoc
    where
        Self::Assoc: Iterator;
}

They differ in what is implied and what is required to be proven:

trait Foo {
    type Assoc
    where
        Self::Assoc: Iterator;
}

fn foo<T: Foo>(xs: T::Assoc) {
    //~^ ERROR `<T as Foo>::Assoc` is not an iterator
    for x in xs {}
}

If we wanted to collect such bounds and make them implied, we certainly could, though. But currently, we don't collect item bounds from the where clauses of an associated type at all.

---

After the PR #120752 lands, a possible way to express this bound would be putting the where clause on the trait, since that's the only place we currently look to collect such item bounds:

trait Foo
where 
    <Self::Bar as Iterator>::Item: Display,
{
    type Bar: Iterator;
}

However, given this stabilization is forwards-compatible with #120752, I'd really rather not block this on that, or any other extensions of implied bounds.

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[rust-timer]

Finished benchmarking commit (21d94a3): comparison URL.

Overall result: no relevant changes - no action needed

@rustbot label: -perf-regression

Instruction count

This benchmark run did not return any relevant results for this metric.

Max RSS (memory usage)

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	6.2%	[6.2%, 6.2%]	1
Improvements ✅ (primary)	-2.4%	[-2.4%, -2.3%]	2
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-2.4%	[-2.4%, -2.3%]	2

Cycles

This benchmark run did not return any relevant results for this metric.

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 669.42s -> 670.018s (0.09%)
Artifact size: 312.82 MiB -> 312.86 MiB (0.01%)