3 ms·

> Before Rust 1.0 it wasn't clear that such a concept of "unmoveability" would be generally useful I'd like to ask, why is moving generally useful? Why would I

> Before Rust 1.0 it wasn't clear that such a concept of "unmoveability" would be generally useful I'd like to ask, why is moving generally useful? Why would I want to move x to y and invalidate x?

steveklabnik 7y ago
We can go back to the reason that Pin even exists in the first place. With Rust, you create a computation, and it implements the Future trait. When you want it to execute, you give it to an executor. This often moves the data structure that represents the computation to the heap, so that it has a stable address, and can continue running after the current stack frame is over. So, before the future starts executing, it can be moved around in memory (and probably will at least one time), but after it starts executing, it must never move again. Does that make sense?
- jimmaswell 7y ago
  So the main use is convenience to seamlessly make stack variables permanent? Intuitively that doesn't sound worth the language design troubles compared to making the programmer declare these things on the heap manually. I'm not that familiar with Rust though.
  - steveklabnik 7y ago
    That’s one use case, it’s not the only one. And it’s not always “put it on the heap”, so you can’t solve the issue that way.
  - kibwen 7y ago
    Ideally it should be possible to avoid the heap entirely; futures in Rust should be capable of operating even in contexts that don't come with a memory allocator, such as memory-constrained embedded devices.
dodobirdlord 7y ago
Rust’s ownership model is used to provide memory safety. Entities have only one owner so that the compiler can reason about when they go out of scope and can be safely dropped. If x didn’t get invalidated by the move then both x and y would own the entity. You could then do something like pass y into a function that would drop y at the end of the function scope, and then cause a use-after-free by using x. With the ownership model the compiler can guarantee that use-after-free is always a syntax error. The ownership model is a fair bit more complicated than this, but move semantics are at the core of it.

> Before Rust 1.0 it wasn't clear that such a concept of "unmoveability" would be generally useful I'd like to ask, why is moving generally useful? Why would I want to move x to y and invalidate x?

steveklabnik 7y ago

We can go back to the reason that Pin even exists in the first place. With Rust, you create a computation, and it implements the Future trait. When you want it to execute, you give it to an executor. This often moves the data structure that represents the computation to the heap, so that it has a stable address, and can continue running after the current stack frame is over. So, before the future starts executing, it can be moved around in memory (and probably will at least one time), but after it starts executing, it must never move again. Does that make sense?

jimmaswell 7y ago
So the main use is convenience to seamlessly make stack variables permanent? Intuitively that doesn't sound worth the language design troubles compared to making the programmer declare these things on the heap manually. I'm not that familiar with Rust though.
- steveklabnik 7y ago
  That’s one use case, it’s not the only one. And it’s not always “put it on the heap”, so you can’t solve the issue that way.
- kibwen 7y ago
  Ideally it should be possible to avoid the heap entirely; futures in Rust should be capable of operating even in contexts that don't come with a memory allocator, such as memory-constrained embedded devices.

dodobirdlord 7y ago

Rust’s ownership model is used to provide memory safety. Entities have only one owner so that the compiler can reason about when they go out of scope and can be safely dropped. If x didn’t get invalidated by the move then both x and y would own the entity. You could then do something like pass y into a function that would drop y at the end of the function scope, and then cause a use-after-free by using x. With the ownership model the compiler can guarantee that use-after-free is always a syntax error. The ownership model is a fair bit more complicated than this, but move semantics are at the core of it.