5.11 Variability
Variability is the ability to change certain values, and the rust language differs greatly from other languages. The 1th is that rust is immutable by default:
Let x = 5;x = 6; error!
We can introduce mut keywords to increase variability:
Let mut x = 5;x = 6; No problem!
This is a mutable binding. When a binding is variable, you can change the value that the bindings point to. In the previous example, the value of x did not change much, but the binding shifted from one i32 to another i32.
If you need to change the value of a binding, you need a mutable reference:
Let mut x = 5;let y = &mut x;
Y is an immutable binding that binds to a mutable reference, which means you cannot bind Y to other values (y = &mut z), but you can modify the value of the Y-bound object (*y = 5). The difference is subtle. Of course you can also declare them both: let mut x = 5;let Mut y = &mut x;
Now you can bind Y to other objects, and the value of the object Y points to can be modified.
Mut is part of the pattern that you can do:
Let (Mut x, y) = (5,6); FN foo (mut x:i32) {
5.11.1 internal and external variability
However, when we say something is immutable, it is not that he cannot be changed: we mean that it has external variability. Take a look at the example of arc<t>:
Use Std::sync::arc;
Let x = Arc::new (5), let y = X.clone ();
When we call the Clone () function,,arc<t> needs to update its reference count. And we're not using any mut,x is an immutable binding, and we're not using &mut 5 or anything else. So who gave it the variability?
To understand this, we need to go back to the core content of Rust's design philosophy, memory security, and Rust's mechanisms for providing memory security, ownership systems, and more specifically, borrowing:
You can have one or more of the following two types of borrowing, but you cannot have both:
- 1 or more references (&t)
- A mutable reference (&mut T)
So, that's the true definition of immutability: Is it safe to have two pointers? In the arc<t> example, yes: variability is completely contained within the structure itself. He is not user-oriented. So, it surrendered the &t through clone. But if it had surrendered the &mut T, that's bad.
Other types, such as those in the Std::cell module, have the opposite side: internal variability. For example:
Use Std::cell::refcell;
Let x = refcell::new, let y = X.borrow_mut ();
Refcell the Borrow_mut () method to surrender its own internal &mut reference. Isn't this unsafe? If we do:
Use Std::cell:refcell;
Let x = Refcell::new ("a") = X.borrow_mut (); Make z = X.borrow_mut (); At run time, this will panic. Refcell did this: at run time, if Rust's borrowing rules were violated, it would force the program to panic. This will lead us to the rule of another rust's variability. Let's take a look at it first.
Local variability (Field-level mutability)
Variability is a feature of borrowing (&mut) and binding (let Mut). You can't hold a struct, it has a mutable member and a non-convertible:
struct Point {x:i32, Mut y:i32,//Nope}
The variability of a struct is in its binding:
struct Point {
X:I32,
Y:I32,
}
Let mut a = point {x:5, y:6};
a.x = 10;
Let B = Point {x:5, y:6};
b.x = 10; Error:cannot Assign to immutable field ' b.x '
However, by Cell<t>, you can change the variability of member variables:
Use Std::cell::cell;
struct Point {x:i32, y:cell<i32>,}
Let point = point {X:5, y:cell::new (6)};
Point.y.set (7);p rintln! ("Y: {:?}", Point.y);
This prints Y:cell {value:7}. We have successfully updated the value of Y.
Rust Chinese Translation 30
