3 ms·

I like this idea of using explicit builtins like move() to transfer ownership rather than implicit transfers through assignment based on the source & destinatio

I like this idea of using explicit builtins like move() to transfer ownership rather than implicit transfers through assignment based on the source & destination types and the context. It makes the intent MUCH easier to follow, and also affords the compiler with more information about your intentions so that it can diagnose better if you screw something up. Rust code would be much easier to read and maintain if it had this...

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 ago
  That why the next step is to introduce move-only types to have the same defaults as Rust.

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 ago
That why the next step is to introduce move-only types to have the same defaults as Rust.