Why Rust's ownership/borrowing is hard
softwaremaniacs.org
Why Rust's ownership/borrowing is hard
1–10 of 67 posts
Re: Why Rust's ownership/borrowing is hard
#2Try a temporary variable for state, then use the consume in a scoped let block.
Re: Why Rust's ownership/borrowing is hard
#3There were also some interesting comments yesterday when this was posted to the Rust subreddit:
https://www.reddit.com/r/rust/comments/45gcmh/why_rusts_owne...
Re: Why Rust's ownership/borrowing is hard
#4Why is move the default? In many code bases the number of immutable references outweighs that of pointers.
Re: Why Rust's ownership/borrowing is hard
#5Why is move the default? In many code bases the number of immutable references outweighs that of pointers.
For 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.
Re: Why Rust's ownership/borrowing is hard
#6Why is move the default? In many code bases the number of immutable references outweighs that of pointers.
For 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 create…
You mean it's forcing you realize this and restructure your code to free resources early like an eager collector?
Re: Why Rust's ownership/borrowing is hard
#7Why is move the default? In many code bases the number of immutable references outweighs that of pointers.
That 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.
Re: Why Rust's ownership/borrowing is hard
#8Why is move the default? In many code bases the number of immutable references outweighs that of pointers.
In 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.
Re: Why Rust's ownership/borrowing is hard
#9Earlier quoted context omitted.
For 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 create…
You mean it's forcing you realize this and restructure your code to free resources early like an eager collector?
That'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.).
Re: Why Rust's ownership/borrowing is hard
#10Why is move the default? In many code bases the number of immutable references outweighs that of pointers.
That 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.
I 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.