Implement associated items

[alexcrichton]

Tracking issue for rust-lang/rfcs#195

This meta-bug contains links to the most significant tasks remaining for associated items. For a comprehensive listing of bugs, please search using the A-associated-items label.

Post 1.0 Tasks

• Normalize associated types used in where clauses (#20765) and associated type bounds (#20775)
• Implement associated lifetimes (see Issue #17842),
• Update library code for associated constants (see Issue #17825).

Completed Tasks

• Implement associated output types (see PR #16377),
• Update library code for associated output types (see Issue #17826),
• Implement multi-dispatch (see PR #17669),
• Update library code for multi-dispatch (see Issue #17827),
• ICE: Unbound path #17388
• Clarify outlives requirements on projected types (#20303)
• Integrate projection types into method dispatch #20469
• Some types not normalized? #20604
• ICE with missing impl items #20347
• Associated types should permit builtin bounds (#17921)
• Implement Trait<Out=Type> syntax (#18432)
• Support T::Type syntax (#18433)
• Associated types are used as inputs for multidispatch (#18437)
• Traits with associated types appearing on structs, enums, or other traits (#18768)
• Qualified paths don't check type arguments in the trait reference (#18865)
• rustdoc panics when dealing with associated types (#18594)
• Associated types should permit arbitrary bounds (#18178)
• Associated types need to do transitive bound expansion (#18434)
• Traits with where clauses that themselves reference traits with assoc types (#18436)
• Integrate object projection predicates into rustdoc (#20299)
• Convert T::Foo resolution to use where clauses, not bounds (#20300)
• Implement associated constants (see Issue #17841),
• Implement defaults for associated types (see issue #19476),

Declined tasks

• Permit unqualified references to associated types of the trait within the trait definition (#18764)
• Update library code for associated lifetimes (see Issue #17828),

[pnkfelix]

there is debate about whether this contains P-backcompat-lang issues for 1.0, or if the 1.0 issues are solely P-backcompat-libs.

Leaving as I-nominated so that people can take a week teasing apart the sub-issues that stem from the RFC.

[pnkfelix]

leaving I-nominated for anohter week again! assigning to myself to spawn off subissues.

[pnkfelix]

punting for another week...

[aturon]

@pnkfelix Want to coordinate this work this week? I want to do an evaluation of how much of associated items has landed in terms of what we need for the libraries, and that could help inform the division into subissues/nominations. Let me know.

[pnkfelix]

@aturon sure, happy to coordinate. I'm going to actually look at it now; I will either open subissues directly, or, if I do not feel comfortable doing so, then I'll email you with my findings.

[pnkfelix]

Okay I think I've opened all the subbugs I can think of, and my spreadsheet (google doc) at least represents a hackish sketch of what might need to do be done (though I did not look at libserialize, std::ascii, nor std::io yet.

Anyway, if this sits idle until the next triage meeting, my official recommendation is that we nominate one or more of the tickets that I opened that point to this ticket, and then we remove the nomination from this ticket (since it is a metabug, quite literally now).

[aturon]

@pnkfelix Thanks for doing this!

One further issue: right now, associated types are (largely) working, and multidispatch is on the way. But associated constants, lifetimes and inherent items are not implemented.

We may want to break those into further issues, so we can triage each part separately. For example, I don't think associated constants need to be 1.0 (we can work around it reasonably in the libraries), but associated lifetimes probably are (because we intend not to allow lifetimes as "input" parameters on a trait, but you need some way to talk about them.)

[pnkfelix]

@aturon wait, I thought "breaking those into further issues" is exactly what I did by filing #17825 #17826 #17827 #17828 ... I feel like I must be misunderstanding you.

[aturon]

@pnkfelix The new issues appear to focus on rolling out the features for the libraries, but don't mention actually implementing them :-) but probably they can be triaged together?

[pnkfelix]

@aturon oh yes I see; you are right, we still need issues for the language changes themselves. But the triage can focus on the library back-compat and stabilization issues, right? That was driving my focus

[aturon]

@pnkfelix Yep, sounds fine -- and honestly, those issues can probably cover both the implementation and the library work, since the two go hand-in-hand.

[pnkfelix]

removing i-nominated tag. yay

[nikomatsakis]

I have been working on this a little. I am going to repurpose this issue to mean specifically bounds that are not builtin types, since builtin type bounds are covered by #17921

[carllerche]

I am currently hitting issues #17388 and #18757, #17732.

[cmr]

I'm hitting #17388, #18764, and #17732 as well.

[mitsuhiko]

I'm hitting #18819 which looks a bit like #17732 but different.

[nrc]

Should there be a work item for defaults for associated types? (I think this is in the RFC)

[aturon]

@nick29581 I added it to the list, but didn't create an issue yet.

[quantheory]

#19129 (ICE implementing trait with generic parameter and associated type) should be on this list. Unfortunately it prevents the fix for #17388 from really helping much; even though some of the previously affected traits now compile, you can't actually implement any functions associated with those traits.

[aturon]

@quantheory Added, thanks!

[P1start]

Adding lifetime as a keyword is a backwards-incompatible language change. Is there an issue for this somewhere, and if so, can it be added to this list?

[nikomatsakis]

Meta-note: the top-level comment includes all bugs listed so far that have not yet been fixed.

[rrichardson]

Found a possible bug wrt to traits which have types which are Deref: #20502

[carllerche]

My current associated type blockers:

Constraints on nested associated types: #20543
Default type parameters w/ associated types: #20540 (more of a severe API ergonomic issue)

[edwardw]

cc me

[bluss]

I updated the list in this issue. A lot of items are done now!

[retep998]

Has #8995 been lost from this list somehow?

[bltavares]

Triaging: #20765 and #17825 are closed.

[alexcrichton]

This has basically all long since been implemented, so closing.

[dashed]

This isn't implemented yet: #8995

[Centril]

What happened to associated const bounds as in the following? An omission perhaps?

trait Foo {
    const Bar: usize;
}

fn baz<T: Foo<Bar = 1>>() {}

cc @SergioBenitez