6 ms·
Why is move the default? In many code bases the number of immutable references outweighs that of pointers.
by cm3 11y ago
Why is move the default? In many code bases the number of immutable references outweighs that of pointers.
- dikaiosune 11y agoFor me at least, it's nice to have a language feature which tells me "BTW, the borrow checker is about to start caring about how long this memory is around." As opposed to the opposite, which is that everything you ever do will trigger the lifetime checks for passing arguments, and you would have to explicitly tell it to go away and that you want ownership to move. Edit: I'm referring to the `&` operator which creates a reference/pointer to the memory it precedes.
- cm3 11y agoYou mean it's forcing you realize this and restructure your code to free resources early like an eager collector?
- dikaiosune 11y agoThat's one pleasant effect (although a bit orthogonal to what I was referring to), because my default behavior in Rust is to pass ownership which results in that memory being dropped as soon as it's no longer needed. I guess what I'm referring to is that I think reasoning about the borrow checker is easier when references are opt-in instead of being the default. That behavior is re-enforced by the fact that the language's default is ownership. So I only end up needing to think hard about the lifetime of a variable when I've decided to (or been explicitly forced to) use references. I think it's a good way to reduce the cognitive burden of an already unfamiliar mechanism. EDIT: This also gets at one of my favorite parts of Rust: so many choices have been made in designing the language and standard library that make it so easy to do things "the right way" (either through those things being the default, or making it hard to do stupid things, etc.).
- steveklabnik 11y agoThat way the syntax is the same everywhere. Reference by default would look different, and then you'd need a sigil for move, etc. pcwalton said that back in the 0.1 days this was actually implemented, and it was very confusing.
- cm3 11y agoI remember it but the language changed so often that I didn't recall this right away. At least it's tried and scrapped and not based on some opinion.
- cm3 11y agoI mean, like in Haskell the hard earned wisdom is that laziness should probably have been opt-in like OCaml making you write the rec keyword for recursive functions. I hope that one day we will get TCO in Rust as it's natural to implement many things recursively.
- riffraff 11y ago> in Haskell the hard earned wisdom is that laziness should probably have been opt-in like OCaml is it? I am no haskeller, but I think I have seen some presentations or read papers in which lazyness by default was mentioned as something that haskell got right. Do you have some links to read up on what you say?
- jonreem 11y agoIn early rust, you actually did need to explicitly write `move` to move a value. However, this was extremely annoying as you move values a lot so moving was changed to be the default, which is far more tolerable. EDIT: There still is a `move` keyword, but it is used to indicate that closures should take ownership of their environment vs. just borrow values from it, not to move individual values.
- deleted 11y ago[deleted]