std: Stabilize IteratorExt::cloned

[alexcrichton]

This commit stabilizes the cloned iterator after tweaking the signature to
require that the iterator is over &T instead of U: Deref<T>. This method has
had time to bake for awhile now and it's not clear whether the Deref bound is
worth it. Additionally, there aren't clear conventions on when to bound and/or
implement the Deref trait, so for now the conservative route is to require
references instead of U: Deref<T>.

To change this signature to using Deref would technically be a
backwards-incompatible change, but it is doubtful that any code will actually
break in practice.

[rust-highfive]

r? @aturon

(rust_highfive has picked a reviewer for you, use r? to override)

[bluss]

I assume Option::cloned will go the same way, since it is very much the same.

[aturon]

@alexcrichton I have mixed feelings about this signature change -- it's both less flexible, and possibly less clear. Can you expand a bit on the motivation for the change? (I do agree that we don't have a convention yet, but conventions often arise from examples like this.) That said, I don't care too much either way.

cc @gankro

[Gankra]

The primary motivation of Deref was to unify & and &mut. Granted: I can't think of any place where you'd only have an &mut but couldn't do & (maybe a generic context...?). Being able to rip through Box's/Rc's/Whatever is just gravy that I wasn't super concerned with.

[aturon]

Thanks @gankro!

So I guess the main reason to simplify as this PR is doing is to use "less magic", which seems OK to me. If/when we get equality constraints, we can express the same signature more concisely.

@bors: r+ 7c333e9

(Also note @bluss's comment about this method elsewhere.)

[alexcrichton]

I have mixed feelings about this signature change -- it's both less flexible, and possibly less clear.

I do agree that the signature went a bit south, I was not super happy that type/lifetime parameters needed to be added.

Can you expand a bit on the motivation for the change?

My main motivation was that we have very few functions which are abstract over Deref today and it seems too powerful for this purpose where the major use case is &T => T. I had forgotten, however, about @gankro's original motivation of abstracting over both &mut T and &T, though. In general I feel that the power of Deref outweighs the benefit of cloned on Iterator<Item=&mut T> though.

I assume Option::cloned will go the same way, since it is very much the same.

If we stabilize Option::cloned I'd definitely want to give it the same treatment!