The following code deadlocks because the mutex is not unlocked after the last use of v:
use std::sync::{Arc,Mutex};
fn main() {
let a = Arc::new(Mutex::new(3));
let mut v = a.lock().unwrap();
*v += 1;
println!("v is {v}");
// drop(v);
let b = Arc::clone(&a);
std::thread::spawn(move || {
let mut w = b.lock().unwrap();
*w += 1;
println!("w is {w}");
}).join().unwrap();
}
The fix is to uncomment the explicit drop(v). Why does compiler not automatically drop v after its last use?
In contrast, the Rust compiler knows to correctly drop v early in the following case:
fn main() {
let mut a = 3;
let v = &mut a;
*v += 1;
println!("v is {v}");
let w = &mut a;
*w += 1;
println!("w is {w}");
}
This behavior seems natural, I would expect the compiler to do the same above.
Values are dropped when their scope ends, not after their last use. What may be confusing you is that the borrow checker knows references are inconsequential after their last use, and thus considers their lifetimes differently for the purposes of enforcing Rust's referential guarantees.
Technically v in the second example is not dropped until the end of the scope either, but there is no drop logic for references. See What are non-lexical lifetimes?
Related
This code doesn't compile. But it fails on the last line marked Err, not the line marked Ok. Why can we assign a mutable reference to an immutable reference type but not use it after the assignment?
fn main() {
let mut x = 10;
let mut y = 20;
let mut r = &x;
r = &mut y; //Ok
*r = 30; //Err
}
Why can we ... not use it after the assignment?
The variable r is an immutable reference of type &i32; it does not have mutable access to the referenced value. So it makes sense the compiler would reject your attempt to assign through it.
Why can we assign a mutable reference to an immutable reference type ...?
Why wouldn't you be able to downgrade a mutable reference into an immutable one? The latter is a strict subset of the former. If you were asking about the technicalities instead of the practicalities, its because &mut T to &T is a supported coercion.
If we add explicit types to your code as inferred by the compiler:
fn main() {
let mut x: i32 = 10;
let mut y: i32 = 20;
let mut r: &i32 = &x;
r = &mut y; //Ok
*r = 30; //Err
}
We see that r has type &i32 and not &mut i32, so of course we can't use r to modify the referenced value.
Why can we still do r = &mut y? Simply because we can always use a &mut reference anywhere a & reference is expected (because &mut T implements Deref<Target=T>, allowing coercion to happen).
Consider:
fn main() {
let mut x: i32 = 5;
let y = &mut x;
let z: &i32 = y;
println!("{}", *z);
//*y = 5;
println!("{}", *y);
println!("{}", *z);
}
Without commenting out line 6 the code compiles.
It seems to me that both the reference y and z are in scope from line 5 to 7.
It sure only reads from y, but I've always been told that mutable and immutable reference can not exist at the same time. In fact, it results in a compile error if I replace line 4 with let z: &i32 = &x.
What is going on here?
Immutable references do not expect the underlying value to change and this is problematic if we do have a mutable reference. You can however have multiple immutable references because underlying data is not gonna change.
Scope of reference starts when it is first introduced and ends when it is used for the last time. That means we can add a third mutable reference underneath the println statement
fn main() {
let mut x: i32 = 5;
// scope of y starts here
// we can have multiple immutable references so I moved "mut"
let y = &x;
// scope of z starts here
let z: &i32 = y;
// scope of z ends here
println!("{}", *z);
//*y = 5;
// scope of y ends here
println!("{}", *y);
// this should work
let a = &mut x;
}
Consider the following rust program:
fn main()
{
let mut x = 1;
let mut r = &x;
r;
let y = 1;
r = &y;
x = 2;
r;
}
It compiles without any errors and I agree with that behaviour.
The problem is that I am not able to reach the same conclusion when trying to reason about this formally:
The type of the variable r is &'a i32 for some lifetime 'a.
The type of &x is &'b i32 for some lifetime 'b.
The lifetime 'a includes x = 2;.
From let mut r = &x; we know that 'b: 'a.
Because of 3 and 4 we know that the lifetime 'b includes x = 2;.
Because of 2 and 5 we are doing x = 2; while borrowing x, so the program should be invalid.
What is wrong with the formal reasoning above, and how would the correct reasoning be?
The lifetime 'a includes x = 2;.
Because of 3 and 4 we know that the lifetime 'b includes x = 2;.
They don't. r is reassigned to on line 7, this ends the entire thing as r is thereafter a completely new value independent from the old one -- and yes rustc is smart enough to work at that granularity, that's why if you remove the final x; it will warn that
value assigned to r is never read
at line 7 (whereas you would not get that warning with Go for instance, the compiler doesn't work at that low a granularity).
Rustc can thus infer that the smallest necessary length for 'b stops somewhere between the end of line 5 and the start of line 7.
Since x doesn't need to be updated before line 8, there is no conflict.
If you remove the assignment, however, 'b now has to extend to the last last line of the enclosing function, triggering a conflict.
Your reasoning seems to be that of lexical lifetimes, rather than NLL. You may want to go through the RFC 2094, it is very detailed. But in essence it works in terms of liveness constraints of values, and solving those constraints. In fact the RFC introduces liveness with an example which is a somewhat more complicated version of your situation:
let mut foo: T = ...;
let mut bar: T = ...;
let mut p: &'p T = &foo;
// `p` is live here: its value may be used on the next line.
if condition {
// `p` is live here: its value will be used on the next line.
print(*p);
// `p` is DEAD here: its value will not be used.
p = &bar;
// `p` is live here: its value will be used later.
}
// `p` is live here: its value may be used on the next line.
print(*p);
// `p` is DEAD here: its value will not be used.
Also note this quote which very much applies to your misunderstanding:
The key point is that p becomes dead (not live) in the span before it is reassigned. This is true even though the variable p will be used again, because the value that is in p will not be used.
So you really need to reason off of values, not variables. Using SSA in your head probably helps there.
Applying this to your version:
let mut x = 1;
let mut r = &x;
// `r` is live here: its value will be used on the next line
r;
// `r` is DEAD here: its value will never be used
let y = 1;
r = &y;
// `r` is live here: its value will be used later
x = 2;
r;
// `r` is DEAD here: the scope ends
Life before NLL
Before discussing about non-lexical lifetimes (NLL), let's first discuss the "ordinary" lifetimes. In older Rust before NLL is introduced, the code below won't compile because r is still in scope while x is mutated in row 3.
let mut x = 1;
let mut r = &x;
x = 2; // Compile error
To fix this, we need to explicitly make r out of scope before x is mutated:
let mut x = 1;
{
let mut r = &x;
}
x = 2;
At this point you might think: If after the line of x = 2, r is not used anymore, the first snippet should be safe. Can the compiler be smarter so that we don't need to explicitly make r out of scope like we did in the second snippet?
The answer is yes, and that's when NLL comes in.
Life after NLL
After NLL is introduced in Rust, our life becomes easier. The code below will compile:
let mut x = 1;
let mut r = &x;
x = 2; // Compiles under NLL
But remember, it will compile as long as r is not used after the mutation of x. For example, this won't compile even under NLL:
let mut x = 1;
let mut r = &x;
x = 2; // Compile error: cannot assign to `x` because it is borrowed
r; // borrow later used here
Although the rules of NLL described in RFC 2094 are quite complex, they can be summarized roughly and approximately (in most cases) as:
A program is valid as long as every owned value is not mutated between the assignment of a variable referring to it and the usage of that variable.
The code below is valid because x is mutated before the assignment of r and before the usage of r:
let mut x = 1;
x = 2; // x is mutated
let mut r = &x; // r is assigned here
r; // r is used here
The code below is valid because x is mutated after the assignment of r and after the usage of r:
let mut x = 1;
let mut r = &x; // r is assigned here
r; // r is used here
x = 2; // x is mutated
The code below is NOT valid because x is mutated after the assignment of r and before the usage of r:
let mut x = 1;
let mut r = &x; // r is assigned here
x = 2; // x is mutated
r; // r is used here -> compile error
To your specific program, it's valid because when x is mutated (x = 2), there is no variable referring to x anymore—r is now referring to y because of the previous line (r = &y). Therefore, the rule is still adhered.
let mut x = 1;
let mut r = &x;
r;
let y = 1;
r = &y;
// This mutation of x is seemingly sandwiched between
// the assignment of r above and the usage of r below,
// but it's okay as r is now referring to y and not x
x = 2;
r;
How could know the type of a binding if I use auto type deduction when creating a binding? what if the expression on the right side is a borrow(like let x = &5;), will it be value or a borrow? What will happen if I re-assign a borrow or a value?
Just for check, I do can re-assign a borrow if I use let mut x: &mut T = &mut T{}; or let mut x:&T = & T{};, right?
I sense some confusion between binding and assigning:
Binding introduces a new variable, and associates it to a value,
Assigning overwrites a value with another.
This can be illustrated in two simple lines:
let mut x = 5; // Binding
x = 10; // Assigning
A binding may appear in multiple places in Rust:
let statements,
if let/while let conditions,
cases in a match expression,
and even in a for expression, on the left side of in.
Whenever there is a binding, Rust's grammar also allows pattern matching:
in the case of let statements and for expressions, the patterns must be irrefutable,
in the case of if let, while let and match cases, the patterns may fail to match.
Pattern matching means that the type of the variable introduced by the binding differs based on how the binding is made:
let x = &5; // x: &i32
let &y = &5; // y: i32
Assigning always requires using =, the assignment operator.
When assigning, the former value is overwritten, and drop is called on it if it implements Drop.
let mut x = 5;
x = 6;
// Now x == 6, drop was not called because it's a i32.
let mut s = String::from("Hello, World!");
s = String::from("Hello, 神秘德里克!");
// Now s == "Hello, 神秘德里克!", drop was called because it's a String.
The value that is overwritten may be as simple as an integer or float, a more involved struct or enum, or a reference.
let mut r = &5;
r = &6;
// Now r points to 6, drop was not called as it's a reference.
Overwriting a reference does not overwrite the value pointed to by the reference, but the reference itself. The original value still lives on, and will be dropped when it's ready.
To overwrite the pointed to value, one needs to use *, the dereference operator:
let mut x = 5;
let r = &mut x;
*r = 6;
// r still points to x, and now x = 6.
If the type of the dereferenced value requires it, drop will be called:
let mut s = String::from("Hello, World!");
let r = &mut s;
*r = String::from("Hello, 神秘德里克!");
// r still points to s, and now s = "Hello, 神秘德里克!".
I invite you to use to playground to and toy around, you can start from here:
fn main() {
let mut s = String::from("Hello, World!");
{
let r = &mut s;
*r = String::from("Hello, 神秘德里克!");
}
println!("{}", s);
}
Hopefully, things should be a little clearer now, so let's check your samples.
let x = &5;
x is a reference to i32 (&i32). What happens is that the compiler will introduce a temporary in which 5 is stored, and then borrow this temporary.
let mut x: &mut T = T{};
Is impossible. The type of T{} is T not &mut T, so this fails to compile. You could change it to let mut x: &mut T = &mut T{};.
And your last example is similar.
I have a HashMap<i8, i8> which could contain cycles:
let mut x: HashMap<i8, i8> = HashMap::new();
x.insert(1, 6);
x.insert(3, 5);
x.insert(5, 1);
To get the final value for 3, it should first lookup x[3], then x[5] and finally x[1] which should yield 6. I decided to use a while let loop:
let mut y = x[&3]; // y: i8
while let Some(&z) = x.get(&y) {
y = z;
}
println!("{}", y);
x.insert(0, 0);
This works fine, but it would panic! if 3 is not in the map. As I don't want to do anything about the None case, I want to use a if let (similar to the while let used).
I have tried some notations:
if let Some(&y) = x.get(&3): copies the value, but y is immutable (y: i8)
if let Some(mut y) = x.get(&3): y is mutable, but the value is borrowed (mut y: &i8)
if let mut Some(&y) = x.get(&3): my target: mutable copy, but invalid syntax (mut y: i8)
(All variants are available at Rust Playground, but you need to comment out the third try, as it is invalid syntax)
I would not argue about the second variant, but I need to insert values into my map in the body of the if let. As the map remains borrowed, I can't insert anymore. All I would need is that the value in Some(y) is copied, and y is mutable, so that the borrow checker is satisfied and I can do my recursive lookups.
Your approach #1 is a perfectly correct match, you just need to make the y variable mutable. One possibility is to convert Option<&i8> to Option<i8>, enabling the use of mut y in the pattern. For example, Option::map can dereference the value:
if let Some(mut y) = x.get(&3).map(|ref| *ref) {
Since Copy implies (cheap) Clone, you can express the same using Option::cloned():
if let Some(mut y) = x.get(&3).cloned() {
As of Rust 1.35, you can use Option::copied(), which is only defined for Copy types and just copies the value:
if let Some(mut y) = x.get(&3).copied() {
Another possibility is to leave your approach #1 as-is, but correct it simply by introducing a separate mutable variable inside the if let block:
if let Some(&y) = x.get(&3) {
let mut y = y;
...
Your code basically works:
use std::collections::HashMap;
fn main() {
let mut x: HashMap<i8, i8> = HashMap::new();
x.insert(1, 6);
x.insert(3, 5);
x.insert(5, 1);
let mut key = 3;
while let Some(&z) = x.get(&key) {
key = z;
}
println!("{}", key);
x.insert(key, 0);
}
Here, key is left as the last key that did not match.