Use better generic type parameter names for Extend and FromIterator

[steffahn]

Okay, first some context:

When talking about the Extend trait in a recent meeting, it got really confusing to talk about properties of the Extend trait for a moment because the naming convention on the trait was so weird. It's defined as Extend<A> and has a method extend<T>. But most generic implementations of it look like impl<T> Extend<T> for …iterator-type…, calling the item type T.

I think T is quite sensible for the item type here, so let's change it in the trait definition as well!

That means that <T> for the extend method must go away.. what is that anyway? Yes, it't the IntoIterator parameter that you extend with. Why isn't that just I anyway? Let's choose that! It will be more consistent with existing things like impl<I: Iterator> IntoIterator for I for instance. Or e.g. all of these… 🦀

I've then also noticed FromIterator has the same problem of calling the item A and using T: IntoIterator. Let's change that, too.

....and then of course, there are a “handful” of implementations of these methods that did just copy the signature for fn extend<T> or fn from_iter<T>, so I guess I'm fixing these as well.

---

TL;DR:

Change

pub trait Extend<A> {
    fn extend<T: IntoIterator<Item = A>>(&mut self, iter: T);
    …
}

to

pub trait Extend<T> {
    fn extend<I: IntoIterator<Item = T>>(&mut self, iter: I);
    …
}

to be more consistent with common use of T as the item type in containers, and their Extend impls; and use I as the name for the IntoIterator type.

(first commit)

then also do the basically the same thing for FromIterator<A>→FromIterator<T> as well

(second commit)

Finally, adjust a few a lot of cases of these parameters in trait impls for the abovementioned traits.

(third commit)

These changes obviously don't change/break behavior of the traits and its users, but the improve the way the documentation of the traits renders (the improvement is the more sensible and more consistent names for the parameters). The only downside I'm aware of (besides that this is touching quite a few files.. though I don't feel quite as strongly about all those impls needing change as about the trait definition itself) is that this does affect some link anchor names in some cases. E.g.

- impl<A, V: FromIterator<A>> FromIterator<Option<A>> for Option<V> {
+ impl<T, V: FromIterator<T>> FromIterator<Option<T>> for Option<V> {

would mean that doc.rust-lang.org/core/iter/trait.FromIterator.html#impl-FromIterator<Option<A>>-for-Option<V> no longer works, as it changes …#impl-FromIterator<Option<A>>-for-Option<V> to …#impl-FromIterator<Option<T>>-for-Option<V>

[rustbot]

r? @JohnTitor

rustbot has assigned @JohnTitor.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

• Owners of files modified in this PR: libs
• libs expanded to 12 candidates
• Random selection from JohnTitor, Mark-Simulacrum, clarfonthey, nia-e

[steffahn]

This failure might be spurious, for all I can tell, so let's retry. I might as well rebase now to reduce back the number of commits (integrating the previous two fixes for test failure with the respective change they correspond to) to trigger another run ^^

Edit: Yup, it was a spurious failure, the same test passed now.

[JohnTitor]

Makes sense to me, leaving one nits comment but r=me with or without addressing it.

View changes since this review

[steffahn]

@bors r=JohnTitor

[rust-bors]

@steffahn: 🔑 Insufficient privileges: not in review users

[JohnTitor]

Oh sorry I thought you had, @bors r+

[rust-bors]

📌 Commit 9bca736 has been approved by JohnTitor

It is now in the queue for this repository.