Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Rust's ownership and move semantics

4,612 views

Published on

Rust Samurai 4の資料

Published in: Technology

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.

×