2 ms·
IIRC Rust in its 0.x days had an explicit move keyword, and it was found to be too noisy, and removed. Move by default works great in Rust, and IMHO it's the b
by pornel 5y ago
IIRC Rust in its 0.x days had an explicit move keyword, and it was found to be too noisy, and removed.
Move by default works great in Rust, and IMHO it's the better default. You want to move every time you possibly can, and copy only as little as possible. It's only odd if you're already used to a language like Swift or C++ where implicit copy is the normal behavior. I don't like the implicit copy default, because it either makes unexpected overheads creep in, or leads to paranoia about the invisible behavior, and causes busywork of manually placing `move` everywhere it's applicable.
With move by default you know noting expensive is accidentally copied, and things that really semantically need to be copied have an explicit `.clone()` call. Being able to read where the copies are happening is a massive improvement in readability.
Readable Swift syntax corresponds to the slow version:
init(values: [String]) {
self.values = values;
self.values.sort()
}
fn init(&mut self, values: &[String]) {
self.values = values.to_owned();
self.values.sort();
}
Efficient Swift syntax adds syntactic noise:
init(values: consuming [String]) {
self.values = move(values)
self.values.sort()
}
While the same improvement in Rust removes a call:
fn init(&mut self, values: Vec<String>) {
self.values = values;
self.values.sort();
}
- _old_dude_ 5y agoThat why the next step is to introduce move-only types to have the same defaults as Rust.