The following trait would improve the performance of appending VecDeque to Vec:
pub trait Append<T> {
fn append(&mut self, T);
}
Rust has Extend trait but doesn't have this trait. Why?
How?
Because it has the Extend trait. I don't see why this couldn't be done with Extend.
1 Like
For example, appending Vec<T> to Vec<T>, Vec<T> as Extend<T> uses ptr::write but Vec<T>::append uses ptr::copy_nonoverlapping.
And extend's argument is different from append.
append takes &mut Vec<T> as second argument, so append doesn't consume Vec. You can reuse vector. But when you append Vec to Vec, extend can take Vec<T> or &Vec<T> with T: Copy.
And with specialisation (when that finally lands at some point), extend should be able to do the same thing.
Actually, I wonder if it couldn't be done already as an implementation detail of the standard library. There've been a few cases of std using not-yet stable features.
You should be able to use Vec::drain to get the same semantic effect.
1 Like
I believe there’s already an Extend specialization that works for slice iterators (of Copy types) that ends up doing copy_from_slice, and not individual ptr::writes. Here it is.
1 Like
Oh, I've forgotten drain. Thank you.
Specialization is sufficient to write efficient code.
But it is easier to write less efficient codes not using drain. And I think this is why doc says that when Rust gets specialization, extend_from_slice will likely deprecated but doesn't say so in append. So in my opinion if Rust gets specialization, Rust should have Append trait or not have Vec::append method.
vec1.extend(vec2) calls this specialized implementation:
which does almost the exact same thing as vec1.append(vec2):
Both of them call append_elements which uses copy_nonoverlapping:
The only difference is that extend drops its argument afterward, while append just clears it.
Thank you for your explanation!
Hom about my opinion that Rust should have Append trait or not have Vec::append method?