identify traits in libstd that should use associated types (as output parameters)

[pnkfelix]

as a subtask of #17307, once associated types are implemented, we will want to update libstd to use them, rather than continuing to use type parameters to traits as a way to encode so-called "output types" associated with an impl.

I ran the following ack invocation: ack --rust 'pub.*trait.*<' and then manually surveyed the results to determine the set of traits we might need to update. (I haven't finished the survey yet.)

Here is a google doc with partial results. There are at most 65 cases that I identified via this method, mostly in collections, core::iter, core::ops, and core::slice.

https://docs.google.com/spreadsheets/d/1Y_NAgzEK3FWcG0LjcykyKJEAibSFI3w-v-ekZ4GU8n4/edit?usp=sharing

[pnkfelix]

Nominating.

This is a backward compatibility hazard for our llibraries, so P-backcompat-libs. Furthermore, the libraries in question are pretty fundamental, so I think it may also belong on the 1.0 milestone.

[pnkfelix]

Assigning P-backcompat-libs, 1.0.

[japaric]

There are a few traits like AdditiveIterator that can be "upgraded" to associated types right now, but I can't send a PR until rustdoc learns to deal with associated types (#18594)

[nikomatsakis]

A very good example: the state parameter of the hasher trait. I'd like to identify other cases like this which violate the proposed rules in rust-lang/rfcs#447, as those are higher priority to convert