(I am having trouble grasping lifetimes and ownership in Rust)
Consider the following Rust struct definition:
struct MyType<'lifetime> {
one: &'lifetime u32,
two: &'lifetime u32
}
My current interpretation of the above definition is as follows:
I have defined a struct MyType. The <'lifetime> next to its
identifier refers to a specific lifetime of any one instance of
MyType. The fields one and two are references to u32s, and because they are annotated with 'lifetime, the integers that they refer to are guaranteed to live at least as long as the instance of the struct they belong to.
To challenge my current understanding I created this example:
fn main() {
let num1: u32 = 11;
let instance: MyType;
{ // nested scope
let num2: u32 = 22;
instance = MyType {
one: &num1,
two: &num2
};
println!("{:?}", instance);
}
}
This code compiles and runs (printing MyType { one: 11, two: 22 }), but it seems to disprove my understanding:
As instance gets dropped at the end of main1 and num2 gets dropped at the end of the nested scope right before it, my initial understanding seems false: the integer referred to by the two field didn't live "at least as long as the struct instance".
Where am I wrong? What does the 'lifetime in struct MyType<'lifetime'> actually refer to?
1: I am also unsure if this is correct.
instance gets dropped at the end of main
With the code you've written, this is incorrect. You've discovered non-lexical lifetimes (NLL).
In Rust, a value is only guaranteed to live until the end of its enclosing block if it implements the Drop trait. Otherwise, the compiler is free to end its lifetime when it is no longer used. Since you do not use instance after num2 goes out of scope, this code is acceptable; the lifetime of instance is cut short after its last usage in the println!() call, at which point num2 still exists.
There's a few ways you can make this code fail.
One is to move the println!() call outside of the anonymous block:
fn main() {
let num1: u32 = 11;
let instance: MyType;
{ // nested scope
let num2: u32 = 22;
instance = MyType {
one: &num1,
two: &num2
};
}
// error[E0597]: `num2` does not live long enough
println!("{:?}", instance);
}
The other is to implement Drop on MyType, which disables NLL for values of that type.
impl Drop for MyType<'_> {
fn drop(&mut self) { }
}
This will produce:
error[E0597]: `num2` does not live long enough
...
borrow might be used here, when `instance` is dropped and runs the `Drop` code for type `MyType`
My initial understanding (documented in the quote block in the question) of what <'lifetime> represents in the struct MyType<'lifetime> definition is wrong.
<'lifetime> in the definition of the struct represents a generic type parameter, denoting that MyType contains a reference that borrows something with the 'lifetime lifetime - it does not represent the lifetime of any given instance of the MyType struct.
Related
enum ManagedSlice<'a, T: 'a> {
Borrowed(&'a T),
Owned(T)
}
struct B<'a>{
m: ManagedSlice<'a, Vec<u8>>
}
impl<'a> B<'a> {
pub fn new() -> B<'a> {
let m = ManagedSlice::Owned(vec![]);
B{
m: m
}
}
}
fn main() {
let b = B::new();
}
Playground
I made this code to test if I really understand lifetimes. When I create let b = B::new() I get a B<'x> with a specific lifetime 'x. In theory this should be the lifetime of m. But as you see, m's life is very short, living only inside new.
What happens to a lifetime when something moves? Does m get the lifetime of B?
What about this modification:
enum ManagedSlice<'a, T: 'a> {
Borrowed(&'a T),
Owned(T)
}
struct B<'a>{
m: ManagedSlice<'a, Vec<u8>>
}
impl<'a> B<'a> {
pub fn new(s: &'a u8) -> B<'a> {
let m = ManagedSlice::Owned(vec![]);
B{
m: m
}
}
}
fn main() {
let b;
{
let n = 0;
b = B::new(&n);
}
}
Playground
now I'm forcing 'a to have the lifetime of n. I expected this to not compile since n has a short life and b gets the type B<lifetime of n>, but b has a lifetime greater than n.
What is happening?
Lifetimes aren't variables. You can't make them equal anything, or extend them, or shorten them. They absolutely do not control how long things live.
They're just assertions (or, if you prefer, "claims") that we programmers make about our code:
fn new(s: &'a u8) -> B<'a>
Here you assert that, for each call to new, there's some lifetime 'a for which s will be borrowed and by which the returned B will be parameterised. So far, pretty useless.
Now, the interesting bit:
b = B::new(&n);
Rust knows the assertions you made about B::new, and here is a call to B::new—so it verifies that the assertions hold for this call...
What lifetime could 'a be in this case? Well the compiler knows that the function parameter s, which in this case is the argument &n, is borrowed for 'a; this constrains 'a to being no longer than the life of the borrow &n, which must clearly end before n is dropped upon going out of scope at the end of its block—but we then try to assign the result of the function to b, which exists for a longer lifetime. This violates the assertion we made about the lifetime of the function's return value, and Rust helpfully lets us know about that by failing to compile.
Finally, we only really talk about lifetimes in relation to borrows: when something is owned, it lives as long as it exists (indeed, notice your definition of ManagedSlice does not use its lifetime parameter in the Owned variant); when m is moved into the newly instantiated B, it lives for the life of that B. Furthermore, because m is a ManagedSlice::Owned, the only constraint on 'a is T: 'a, where in our case T is Vec<u8>: it means that 'a cannot outlive anything referenced by the Vec<u8> (such as its underlying heap allocation)—effectively we're asserting the trivially obvious, that the Vec must live at least as long as the B that owns it (but Rust requires this anyway, even if the assertion was not explicitly provided).
What happens to a lifetime when something moves?
A move represents a transfer of data from one memory location to another, rather than a reference to a memory location, which would have a lifetime associated with it. A moved value thus has a lifetime that lasts as long as the variable that holds it is in scope, and moving it will cause the lifetime of the new value to be the time that the new variable holding the value is in scope.
As for your second example, if you add a reference to b outside of the inner block, then you will get the compiler error you expect. The compiler is smart enough to know that even though b is defined in the scope above, it is not used outside of the inner scope, and thus the lifetime of b is equal to the lifetime of &n
I started learning Rust a few days back.
This is an extract from the famous book Programming Rust by Jim Blandy.
For the code
fn g<'a>(p: &'a i32) { ... }
let x = 10;
g(&x);
The book says
Rust Choose the smallest possible lifetime for &x, that of the call to g. This meets all constraints: it doesn't outlive x, and encloses the entire call to g. So code must muster.
Q1. What is meant by the smallest possible lifetime for &x?
For the code
fn f(p: &'static i32) { ... }
let x = 10;
f(&x);
Q2. Why does this code fail? According to my understanding, &'static is used for static global variables which live for the full program. link
A 'static lifetime is a special concept. It specifies that the variable referenced by this needs to exist for the entire lifetime of the program. Using this is a rare case, and requires even rarer precautions to fulfill.
In practice, a &'static reference may only happen in two cases:
A const declaration
A static declaration
Both effectively accomplish the same thing, in different ways; the differences aren't important to this question, however. In both cases, the outcome is a variable that is available for the entire lifetime of the program and will not be relocated, thus guaranteeing &'static if borrowed.
Now that we've covered this, let's cover both of your questions.
Q1. What is meant by the smallest possible lifetime for &x?
When you define a function as fn g<'a>(p: &'a i32) { ... }, you are requiring p to be valid for a lifetime 'a; this lifetime is determined by the compiler so that 'a is the smallest possible. If the reference is never used outside of the function scope, 'a will be the lifetime of execution of that function, for example. If you use or reference this borrow outside of the function, the lifetime will (evidently) be larger.
The definition of "smallest possible" is simple: the compiler will infer the lifetime based from the time you start that reference, to the last time you use that reference. Dependent borrows also count, and this typically comes back to bite people when dealing with collections.
The reason it is the smallest possible is so that you don't run into crazy situations where you don't have a borrow but it is borrowed anyway; this typically happens when you try to provide your own, incorrect, lifetime hints. There are plenty of cases where it is usually best to let the compiler decide; the other case is struct implementations such as the following:
struct Foo<'a> {
item: &'a u32
}
impl<'a> Foo<'a> {
pub fn compare<'b>(&self, other: &'b u32) {
...
}
}
A common fault in situations like this is to describe other to the compiler as 'a, not defining the second 'b lifetime, and thus (accidentally) requiring other to be borrowed for the lifetime of the struct itself.
Q2. Why does this code fail? According to my understanding, &'static is used for static global variables which live for the full program.
let x = 10;
This assignment does not have a 'static lifetime. It has an anonymous lifetime defined as less than 'static, because it is not strictly defined as global. The only way to get a 'static borrow on anything is if that source element is defined as const or static.
You can convince yourself of this with this snippet (playground):
fn f(p: &'static i32) {
println!("{}", p)
}
const FOO:i32 = 3;
static BAR:i32 = 4;
fn main() {
f(&FOO); // Works
f(&BAR); // Also works
}
f(&x);
A 'static lifetime requirement on a reference requires this argument to be declared for the global lifetime of the program, but x cannot fulfill this condition as it is declared midway through execution.
To be able to use this, declare x as const or static so its lifetime will be 'static and the code will work fine.
Why does this code compile?
#[derive(Debug)]
pub struct Foo<'a> {
pub x: &'a [&'a str],
}
fn main() {
let s = "s".to_string();
let t: &str = s.as_ref();
{
let v = vec![t];
let foo = Foo { x: &v[..] };
println!("{:?}", &foo);
}
}
In my Foo struct, my x field contains a slice of &strs. My understanding of these lifetime labels is that the slice and the individual &strs have the same lifetime.
However, in my example the &str t (in the outer block) does not have the same lifetime as the container slice (in the inner block).
My understanding of these lifetime labels is that the slice and the individual &strs have the same lifetime.
This is a common misconception. It really means that there has to be a lifetime that applies to both. When instantiated, the Foo struct's 'a corresponds to the lines of the inner block after let v = vec![t]; as that is a lifetime that both variables share.
If this flexibility didn't exist, lifetimes would be super painful to use. Variables defined on two lines have different actual lifetimes (the one defined first outlives the one defined second). If the lifetimes had to actually match, we'd always have to define all the variables on the same line!
Some more detailed information is available in RFC #738 — Variance.
The syntax 'a is actually used in two different situations:
labeling a loop
indicating a bound
The first situation, labeling a loop:
fn main() {
'a: loop {
println!("{}", 3);
break 'a;
}
}
Here, 'a clearly delineates the lifetime of the loop body, and allows breaking from multiple layers of loops in one fell swoop.
The second, and more similar situation, is using 'a to represent a bound:
fn<'a> susbtr(haystack: &'a str, offset: usize) -> &'a str;
In this case, the lifetime 'a does not represent the actual lifetime of the variable, it represents a bound on the lifetime of the referenced variable and allows tying together the bounds of various variables.
Note that the caller and callee interpret the bound differently:
from the perspective of the caller, 'a is an upper-bound, a promise that the return value will live at least as long as the parameter (maybe longer, no guarantee)
from the perspective of the callee (ie, substr), 'a is a lower-bound, a check that any returned value must live at least as long as the parameter (maybe longer, not necessary)
We can have variance since the bound does not represent the actual lifetime, when a single bound is used for multiple lifetimes, the compiler will simply deduce the lowest/highest bound that makes sense for the situation:
the caller gets the lowest upper-bound feasible (ie, the least guarantee)
the caller gets the highest lower-bound feasible (ie, the least constraint)
For example:
fn<'b> either(one: &'b str, two: &'b str, flag: bool) -> &'b str {
if flag { one } else { two }
}
can be called with:
fn<'a> call(o: &'a str, flag: bool) -> &'a str {
either(o, "Hello, World", flag)
}
Here, the lifetime of o is unknown (some 'a) whilst the lifetime of "Hello, World" is known ('static), 'static is by definition the greater of the lifetimes (it lives for all the program).
the caller of call only knows that the return value lives at least as long as o
call must guarantee this, it supplies o and "Hello, World" to either where 'b is deduced to be the lowest bound between 'a and 'static (thus 'a)
either simply must return something that lives as long as either one of its arguments; it's unaware that their lifetime may differ, and cares not
I am trying to write a function that maps an Arc<[T]> into an Iterable, for use with flat_map (that is, I want to call i.flat_map(my_iter) for some other i: Iterator<Item=Arc<[T]>>).
fn my_iter<'a, T>(n: Arc<[T]>) -> slice::Iter<'a, T> {
let t: &'a [T] = &*n.clone();
t.into_iter()
}
The function above does not work because n.clone() produces an owned value of type Arc<[T]>, which I can dereference to [T] and then borrow to get &[T], but the lifetime of the borrow only lasts until the end of the function, while the 'a lifetime lasts until the client drops the returned iterator.
How do I clone the Arc in such a way that the client takes ownership of the clone, so that the value is only dropped after the client is done with the iterator (assuming no one else is using the Arc)?
Here's some sample code for the source iterator:
struct BaseIter<T>(Arc<[T]>);
impl<T> Iterator for BaseIter<T> {
type Item = Arc<[T]>;
fn next(&mut self) -> Option<Self::Item> {
Some(self.0.clone())
}
}
How do I implement the result of BaseIter(data).flat_map(my_iter) (which is of type Iterator<&T>) given that BaseIter is producing data, not just borrowing it? (The real thing is more complicated than this, it's not always the same result, but the ownership semantics are the same.)
You cannot do this. Remember, lifetimes in Rust are purely compile-time entities and are only used to validate that your code doesn't accidentally access dropped data. For example:
fn my_iter<'a, T>(n: Arc<[T]>) -> slice::Iter<'a, T>
Here 'a does not "last until the client drops the returned iterator"; this reasoning is incorrect. From the point of view of slice::Iter its lifetime parameter means the lifetime of the slice it is pointing at; from the point of view of my_iter 'a is just a lifetime parameter which can be chosen arbitrarily by the caller. In other words, slice::Iter is always tied to some slice with some concrete lifetime, but the signature of my_iter states that it is able to return arbitrary lifetime. Do you see the contradiction?
As a side note, due to covariance of lifetimes you can return a slice of a static slice from such a function:
static DATA: &'static [u8] = &[1, 2, 3];
fn get_data<'a>() -> &'a [u8] {
DATA
}
The above definition compiles, but it only works because DATA is stored in static memory of your program and is always valid when your program is running; this is not so with Arc<[T]>.
Arc<[T]> implies shared ownership, that is, the data inside Arc<[T]> is jointly owned by all clones of the original Arc<[T]> value. Therefore, when the last clone of an Arc goes out of scope, the value it contains is dropped, and the respective memory is freed. Now, consider what would happen if my_iter() was allowed to compile:
let iter = {
let data: Arc<[i32]> = get_arc_slice();
my_iter(data.clone())
};
iter.map(|x| x+1).collect::<Vec<_>>();
Because in my_iter() 'a can be arbitrary and is not linked in any way to Arc<[T]> (and can not be, actually), nothing prevents this code from compilation - the user might as well choose 'static lifetime. However, here all clones of data will be dropped inside the block, and the array it contains inside will be freed. Using iter after the block is unsafe because it now provides access to the freed memory.
How do I clone the Arc in such a way that the client takes ownership of the clone, so that the value is only dropped after the client is done with the iterator (assuming no one else is using the Arc)?
So, as follows from the above, this is impossible. Only the owner of the data determines when this data should be destroyed, and borrowed references (whose existence is always implied by lifetime parameters) may only borrow the data for the time when it exists, but borrows cannot affect when and how the data is destroyed. In order for borrowed references to compile, they need to always borrow only the data which is valid through the whole time these references are active.
What you can do is to rethink your architecture. It is hard to say what exactly can be done without looking at the full code, but in the case of this particular example you can, for example, first collect the iterator into a vector and then iterate over the vector:
let items: Vec<_> = your_iter.collect();
items.iter().flat_map(my_iter)
Note that now my_iter() should indeed accept &Arc<[T]>, just as Francis Gagné has suggested; this way, the lifetimes of the output iterator will be tied to the lifetime of the input reference, and everything should work fine, because now it is guaranteed that Arcs are stored stably in the vector for their later perusal during the iteration.
There's no way to make this work by passing an Arc<[T]> by value. You need to start from a reference to an Arc<[T]> in order to construct a valid slice::Iter.
fn my_iter<'a, T>(n: &'a Arc<[T]>) -> slice::Iter<'a, T> {
n.into_iter()
}
Or, if we elide the lifetimes:
fn my_iter<T>(n: &Arc<[T]>) -> slice::Iter<T> {
n.into_iter()
}
You need to use another iterator as return type of the function my_iter. slice::Iter<'a, T> has an associated type Item = &'a T. You need an iterator with associated type Item = T. Something like vec::IntoIter<T>. You can implement such an iterator yourself:
use std::sync::Arc;
struct BaseIter<T>(Arc<[T]>);
impl<T> Iterator for BaseIter<T> {
type Item = Arc<[T]>;
fn next(&mut self) -> Option<Self::Item> {
Some(self.0.clone())
}
}
struct ArcIntoIter<T>(usize, Arc<[T]>);
impl<T:Clone> Iterator for ArcIntoIter<T> {
type Item = T;
fn next(&mut self) -> Option<Self::Item> {
if self.0 < self.1.len(){
let i = self.0;
self.0+=1;
Some(self.1[i].clone())
}else{
None
}
}
}
fn my_iter<T>(n: Arc<[T]>) -> ArcIntoIter<T> {
ArcIntoIter(0, n)
}
fn main() {
let data = Arc::new(["A","B","C"]);
println!("{:?}", BaseIter(data).take(3).flat_map(my_iter).collect::<String>());
//output:"ABCABCABC"
}
I was reading the lifetimes chapter of the Rust book, and I came across this example for a named/explicit lifetime:
struct Foo<'a> {
x: &'a i32,
}
fn main() {
let x; // -+ x goes into scope
// |
{ // |
let y = &5; // ---+ y goes into scope
let f = Foo { x: y }; // ---+ f goes into scope
x = &f.x; // | | error here
} // ---+ f and y go out of scope
// |
println!("{}", x); // |
} // -+ x goes out of scope
It's quite clear to me that the error being prevented by the compiler is the use-after-free of the reference assigned to x: after the inner scope is done, f and therefore &f.x become invalid, and should not have been assigned to x.
My issue is that the problem could have easily been analyzed away without using the explicit 'a lifetime, for instance by inferring an illegal assignment of a reference to a wider scope (x = &f.x;).
In which cases are explicit lifetimes actually needed to prevent use-after-free (or some other class?) errors?
The other answers all have salient points (fjh's concrete example where an explicit lifetime is needed), but are missing one key thing: why are explicit lifetimes needed when the compiler will tell you you've got them wrong?
This is actually the same question as "why are explicit types needed when the compiler can infer them". A hypothetical example:
fn foo() -> _ {
""
}
Of course, the compiler can see that I'm returning a &'static str, so why does the programmer have to type it?
The main reason is that while the compiler can see what your code does, it doesn't know what your intent was.
Functions are a natural boundary to firewall the effects of changing code. If we were to allow lifetimes to be completely inspected from the code, then an innocent-looking change might affect the lifetimes, which could then cause errors in a function far away. This isn't a hypothetical example. As I understand it, Haskell has this problem when you rely on type inference for top-level functions. Rust nipped that particular problem in the bud.
There is also an efficiency benefit to the compiler — only function signatures need to be parsed in order to verify types and lifetimes. More importantly, it has an efficiency benefit for the programmer. If we didn't have explicit lifetimes, what does this function do:
fn foo(a: &u8, b: &u8) -> &u8
It's impossible to tell without inspecting the source, which would go against a huge number of coding best practices.
by inferring an illegal assignment of a reference to a wider scope
Scopes are lifetimes, essentially. A bit more clearly, a lifetime 'a is a generic lifetime parameter that can be specialized with a specific scope at compile time, based on the call site.
are explicit lifetimes actually needed to prevent [...] errors?
Not at all. Lifetimes are needed to prevent errors, but explicit lifetimes are needed to protect what little sanity programmers have.
Let's have a look at the following example.
fn foo<'a, 'b>(x: &'a u32, y: &'b u32) -> &'a u32 {
x
}
fn main() {
let x = 12;
let z: &u32 = {
let y = 42;
foo(&x, &y)
};
}
Here, the explicit lifetimes are important. This compiles because the result of foo has the same lifetime as its first argument ('a), so it may outlive its second argument. This is expressed by the lifetime names in the signature of foo. If you switched the arguments in the call to foo the compiler would complain that y does not live long enough:
error[E0597]: `y` does not live long enough
--> src/main.rs:10:5
|
9 | foo(&y, &x)
| - borrow occurs here
10 | };
| ^ `y` dropped here while still borrowed
11 | }
| - borrowed value needs to live until here
The lifetime annotation in the following structure:
struct Foo<'a> {
x: &'a i32,
}
specifies that a Foo instance shouldn't outlive the reference it contains (x field).
The example you came across in the Rust book doesn't illustrate this because f and y variables go out of scope at the same time.
A better example would be this:
fn main() {
let f : Foo;
{
let n = 5; // variable that is invalid outside this block
let y = &n;
f = Foo { x: y };
};
println!("{}", f.x);
}
Now, f really outlives the variable pointed to by f.x.
Note that there are no explicit lifetimes in that piece of code, except the structure definition. The compiler is perfectly able to infer lifetimes in main().
In type definitions, however, explicit lifetimes are unavoidable. For example, there is an ambiguity here:
struct RefPair(&u32, &u32);
Should these be different lifetimes or should they be the same? It does matter from the usage perspective, struct RefPair<'a, 'b>(&'a u32, &'b u32) is very different from struct RefPair<'a>(&'a u32, &'a u32).
Now, for simple cases, like the one you provided, the compiler could theoretically elide lifetimes like it does in other places, but such cases are very limited and do not worth extra complexity in the compiler, and this gain in clarity would be at the very least questionable.
If a function receives two references as arguments and returns a reference, then the implementation of the function might sometimes return the first reference and sometimes the second one. It is impossible to predict which reference will be returned for a given call. In this case, it is impossible to infer a lifetime for the returned reference, since each argument reference may refer to a different variable binding with a different lifetime. Explicit lifetimes help to avoid or clarify such a situation.
Likewise, if a structure holds two references (as two member fields) then a member function of the structure may sometimes return the first reference and sometimes the second one. Again explicit lifetimes prevent such ambiguities.
In a few simple situations, there is lifetime elision where the compiler can infer lifetimes.
I've found another great explanation here: http://doc.rust-lang.org/0.12.0/guide-lifetimes.html#returning-references.
In general, it is only possible to return references if they are
derived from a parameter to the procedure. In that case, the pointer
result will always have the same lifetime as one of the parameters;
named lifetimes indicate which parameter that is.
The case from the book is very simple by design. The topic of lifetimes is deemed complex.
The compiler cannot easily infer the lifetime in a function with multiple arguments.
Also, my own optional crate has an OptionBool type with an as_slice method whose signature actually is:
fn as_slice(&self) -> &'static [bool] { ... }
There is absolutely no way the compiler could have figured that one out.
As a newcomer to Rust, my understanding is that explicit lifetimes serve two purposes.
Putting an explicit lifetime annotation on a function restricts the type of code that may appear inside that function. Explicit lifetimes allow the compiler to ensure that your program is doing what you intended.
If you (the compiler) want(s) to check if a piece of code is valid, you (the compiler) will not have to iteratively look inside every function called. It suffices to have a look at the annotations of functions that are directly called by that piece of code. This makes your program much easier to reason about for you (the compiler), and makes compile times managable.
On point 1., Consider the following program written in Python:
import pandas as pd
import numpy as np
def second_row(ar):
return ar[0]
def work(second):
df = pd.DataFrame(data=second)
df.loc[0, 0] = 1
def main():
# .. load data ..
ar = np.array([[0, 0], [0, 0]])
# .. do some work on second row ..
second = second_row(ar)
work(second)
# .. much later ..
print(repr(ar))
if __name__=="__main__":
main()
which will print
array([[1, 0],
[0, 0]])
This type of behaviour always surprises me. What is happening is that df is sharing memory with ar, so when some of the content of df changes in work, that change infects ar as well. However, in some cases this may be exactly what you want, for memory efficiency reasons (no copy). The real problem in this code is that the function second_row is returning the first row instead of the second; good luck debugging that.
Consider instead a similar program written in Rust:
#[derive(Debug)]
struct Array<'a, 'b>(&'a mut [i32], &'b mut [i32]);
impl<'a, 'b> Array<'a, 'b> {
fn second_row(&mut self) -> &mut &'b mut [i32] {
&mut self.0
}
}
fn work(second: &mut [i32]) {
second[0] = 1;
}
fn main() {
// .. load data ..
let ar1 = &mut [0, 0][..];
let ar2 = &mut [0, 0][..];
let mut ar = Array(ar1, ar2);
// .. do some work on second row ..
{
let second = ar.second_row();
work(second);
}
// .. much later ..
println!("{:?}", ar);
}
Compiling this, you get
error[E0308]: mismatched types
--> src/main.rs:6:13
|
6 | &mut self.0
| ^^^^^^^^^^^ lifetime mismatch
|
= note: expected type `&mut &'b mut [i32]`
found type `&mut &'a mut [i32]`
note: the lifetime 'b as defined on the impl at 4:5...
--> src/main.rs:4:5
|
4 | impl<'a, 'b> Array<'a, 'b> {
| ^^^^^^^^^^^^^^^^^^^^^^^^^^
note: ...does not necessarily outlive the lifetime 'a as defined on the impl at 4:5
--> src/main.rs:4:5
|
4 | impl<'a, 'b> Array<'a, 'b> {
| ^^^^^^^^^^^^^^^^^^^^^^^^^^
In fact you get two errors, there is also one with the roles of 'a and 'b interchanged. Looking at the annotation of second_row, we find that the output should be &mut &'b mut [i32], i.e., the output is supposed to be a reference to a reference with lifetime 'b (the lifetime of the second row of Array). However, because we are returning the first row (which has lifetime 'a), the compiler complains about lifetime mismatch. At the right place. At the right time. Debugging is a breeze.
The reason why your example does not work is simply because Rust only has local lifetime and type inference. What you are suggesting demands global inference. Whenever you have a reference whose lifetime cannot be elided, it must be annotated.
I think of a lifetime annotation as a contract about a given ref been valid in the receiving scope only while it remains valid in the source scope. Declaring more references in the same lifetime kind of merges the scopes, meaning that all the source refs have to satisfy this contract.
Such annotation allow the compiler to check for the fulfillment of the contract.