Vec::extend_from_slice’s documentation forgot about the difference of T: Clone vs. T: Copy bounds.

[steffahn]

Quoting from https://doc.rust-lang.org/nightly/std/vec/struct.Vec.html#method.extend_from_slice

Note that this function is same as extend except that it is specialized to work with slices instead.

But Vec::extend_from_slice supports &[T] for T: Clone, whereas Vec::extend only supports impl Iterator<Item = &T> if T: Copy, so it’s not the same.

[cuviper]

FWIW, rust-lang/rfcs#839 debated whether Extend<&T> should require T: Clone or T: Copy, and the consensus was to start with Copy and consider Clone later. But I think that would be a breaking change to expand that blanket impl, because downstream impl Extend<&Foo> for Vec<Foo> is allowed if Foo is not Copy -- but it may be Clone.

[steffahn]

Interesting discussion to read, thanks for the link. I agree with your observation that the supposedly backwards compatible change that it ended on would be breaking; at least since 1.41.0, before that release it was probably actually still backwards compatible edit.. nevermind it always was breaking, 1.41 just introduced to possibility to have generic arguments in the foreign Self type, too.

[jyn514]

I thought we have a policy that adding new impls isn't considered a breaking change? I guess relaxing a bound is technically not the same as adding an impl but it seems effectively the same ...

[cuviper]

There's a difference between adding new impls for concrete types, which can't conflict downstream but may cause call ambiguity, versus adding or expanding a generic impl that could conflict with downstream impls.