Successfully reported this slideshow.
Your SlideShare is downloading. ×

Rust's ownership and move semantics

More Related Content

Related Books

Free with a 30 day trial from Scribd

See all

Rust's ownership and move semantics

  1. 1. Rust’s “Ownership” & Move Semantics on Rust v.0.12-pre, 2014. Sep. 24. presentation in Rust Samurai 4
  2. 2. Rust has rules: • lifetime • ownership • borrowing
  3. 3. Lifetime “Lifetime” concept is a time span which a resource (variable) life is valid in.
  4. 4. Lifetime (we have seen this graph in Rust guide, tutorial, or somewhere…) { let a = 1; { let b = 1; … … … } }
  5. 5. Lifetime • You can think “Lifetime” is like a scope. • On the end of the lifetime, the resource will be destructed (freed).
  6. 6. Ownership We can attempt that: all allocated memory is “owned” by a unique someone.
  7. 7. Ownership let x = v; x owning v
  8. 8. Ownership • The “owner” can change the owning value according to mutability. • Ownership can transfer to an other variable. • This is just move semantics in Rust. • Ownership model guarantees the safeness in parallel.
  9. 9. Borrowing We can “borrow” the resource which is owned by the other.
  10. 10. Borrowing x owning v y Borrowing is similar to “reference”.
  11. 11. Borrowing • “Borrowing” is similar to “reference”of other language. • “Borrowing” is just only “borrowing” the resource which is owned by the other. • “Borrowing” is under some restrictions in ownership concept.
  12. 12. Some restrictions about Ownership/Borrowing
  13. 13. Fundamental principals • The borrowed value must not change without explicitly. • If it changes arbitrarily, it is unclear and violates a safety of program.
  14. 14. Why we need a restriction? • For safety. • The arbitrary (non-explicit) change causes some serious safety issues. • e.g. If the pointer is changed to the other location or `null` without explicitly while it is borrowed (referenced) from other?
  15. 15. Borrowing restrictions • Borrowing cannot change the borrowed one without mutable permission by owner. • Likewise, the original owner cannot change the owning value if it’s borrowed from others. • We cannot borrow the same value as mutable more than once time.
  16. 16. Cannot assign to immutable dereference let mut x: int = 1; { let y = &x; *y = 10;// error: cannot assign } x = 2;// this is valid
  17. 17. Cannot assign to immutable dereference if you wanna change `y`, `y` must be `&mut int` let mut x: int = 1; { let y = &x; *y = 10;// error: cannot assign } x = 2;// this is valid
  18. 18. let mut x: int = 1; { let y = &x; let z = &mut x; // error! } Cannot mutable borrow, if the target has already been borrowed (and vise versa)
  19. 19. let mut x: int = 1; { let y = &x; let z = &mut x; // error! } Cannot mutable borrow, if the target has already been borrowed (and vise versa) This cannot ensure that the borrowed value by `y` is expected one.
  20. 20. Cannot mutable borrow, more than once time let mut x: int = 1; { let y = &mut x; let z = &mut x; // error! }
  21. 21. Cannot mutable borrow, more than once time let mut x: int = 1; { let y = &mut x; let z = &mut x; // error! } This cannot ensure that the borrowed value by `y` is expected one.
  22. 22. Cannot change the value during it’s borrowed let mut x: int = 1; let y = &x; // after this, cannot change `x` x = 10; // compile error!
  23. 23. Cannot change the value during it’s borrowed (sometimes called “freeze”) let mut x: int = 1; let y = &x; // after this, cannot change `x` x = 10; // compile error! This cannot ensure that the borrowed value by `y` is expected one.
  24. 24. Move semantics In Rust, “move semantics” is transferring an ownership.
  25. 25. Move semantics • Transfer the ownership to the other. • If we can move the ownership, as the result, we can assign the value with zero-copy like C++. • Because Ownership concept ensures: • Type system invalidates the old value. • Then, there is no some owners, just only 1 owner!
  26. 26. How transfer the ownership?
  27. 27. • The typical case is copying Owned Box (std::owned::Box<T>). • This copy is a shallow copy (Owned box is just like pointer), but Rust compiler consider to move ownership of the boxed value. { let x: Box<int> = box 1; let y = x; // `x` is moved here! (`x` will dead) println!(“{}”, x); // compile error. `x` has been moved }
  28. 28. • What will it happen if we don’t move ownership hold by Owned Box? • Then, there will be some inconsistency. • If we do shallow-copy the value of Owned Box, there will be some objects that has the ownership of same location. This is against the rule. • If we do deep-copy the value of it, we don’t have to use Owned box!
  29. 29. What type is a target of move? • Almost, non-Copy kind, or ‘static kind. • Move semantics is closely related to Rust’s type system. • the value returning by function, or block. • Send the value to other tasks (We can send only Send kinds).
  30. 30. Type kinds • Send • All Send are ‘static kind. • All types contains owning types, they must be Send. • Copy • Plain Old Data. • ‘static • Drop • Send only can implement Drop. • Default
  31. 31. Move: type need to move. • `Send` kind • Contains owning pointers. • `Drop` kind (Implements `Drop` trait). • procedure's environment • non first-class types (but no details in rust doc…)
  32. 32. Move: the return value. • The value returned by `return`, it’s would be moved from function/block. (This behavior is explained as “set to output slot”.)
  33. 33. Move: parameter type is opaque • when `fn bar<T>(a: T) {…}`, we cannot specify the expected behavior. • In this case, this parameter type can be only move. We must move it because we must ensure that it moves all ownerships of contained fields. • If we specified the trait bound like `T: Copy`, this parameter will be copy.
  34. 34. Move: transfer a data from the task to other tasks • In this case, the sent data must be `Send` kinds.
  35. 35. Move: procedure’s env. • procedures may only be invoked once. • After call them once, they are moved out.
  36. 36. Conclusion
  37. 37. Conclusion • Rust has “ownership” concept to ensure the memory safety. • “Ownership” consists of lifetime. • Some types transfer their ownership if they’re re-assigned to other variables by following move semantics.

×