In this ppt, we will explore how to manage lifetimes in rust in complex situations and where rust brings an upper hand over conventional languages.
These slides cover:
- Ownership and References
- Borrowing and Borrow Checking
- Explicit annotation of a lifetime
- Advanced concept of a lifetime such as a Lifetime Elision
2. Session
Etiquettes
● Respect session timings, you are requested not to join sessions
after a 5 minutes threshold post the session start time.
● Make sure to submit a constructive feedback for all sessions as
it is very helpful for the presenter.
● Keep your mobile devices in silent mode, feel free to move out
of session in case you need to attend an urgent call.
● Avoid unwanted chit chat during the session.
4. Ownership
1. Each value in Rust has a variable known as its Owner.
2. There can be only one owner at a time.
3. When the owner goes out of scope, the value will be
dropped.
8. How does the
compiler know?
● Rust compiler has a borrow checker
● Borrow checker compares the scope of the reference
variable and the variable it is referencing.
● It ensures that the subject of reference variable lives
at least as long as the reference variable.
9.
10. What if we can’t tell if a reference is valid?
11. We need to ensure that what the function may
return is valid.
12. Lifetime
Annotation
● A notation which describes relative lifetimes of
references.
● It never changes the lifetime of the references, just
constraints a specific lifetime.
● It tells that the references are valid for at least that
amount of time.
13. Lifetime
Annotation
● Syntax starts with an ‘ followed by a small case name
which is generally a single letter.
● fn<’a> foo(param1: &’a type) -> &’a return_value
● fn<’a> foo(param1: &’a mut type)->&’a return_value
14. How do we
calculate ‘a ?
● ‘a refers to the lifetime in which all the related
references are valid, which is the overlap all of the
references’ lifetimes.
● As a result, the smallest lifetime of all the references
gets assigned to ‘a.
15. Lifetime in Structs
● Struct fields could be a reference variable.
● In structs, they imply that the instance of a structure
can not out live the subject of reference of the field.
16. Lifetime Ellison
● Some coding patterns were very common and hence
annotating them was considered an overhead.
● Rust identified a few of them and designed some
rules.
● These rules are tested for at compile time and are
used to determine the lifetimes.
17. Lifetime Ellison
Rules
● Each input parameter gets its own lifetime
parameter.
● If there’s only one input parameter, its lifetime is
assigned to the returned value.
● If there are multiple input parameters but one of
them is &self or & mut self, it’s lifetime is assigned to
the returning value.
18. Lifetime Ellison
● If the compiler parses this code without any
annotation and there is no reference who’s lifetime is
not determined, the code is compiled successfully
● If the compiler can’t infer the lifetime of any
reference, it throws an error.
● These aren’t to follow, but available at the disposal of
the developer.
19. Static Lifetime
● Denotes lifetime of entire duration of the program.
● Denoted by ‘static.
● Means the reference can outlive anything.
● Anything static is directly provided inside the binary
of the program.
20. Static Lifetime
Variables with static lifetimes can be declared by two ways:
1. By declaring static constants
static AGE: i32 = 25;
2. By declaring string literals
let name: &’static str = “ayush prashar”;