mirror of https://github.com/rust-lang/book
230 lines
9.1 KiB
Markdown
230 lines
9.1 KiB
Markdown
|
## Variables and Mutability
|
|||
|
|
|
|||
|
|
As mentioned in Chapter 2, by default variables are immutable. This is one of
|
|||
|
|
many nudges Rust gives you to write your code in a way that takes advantage of
|
|||
|
|
the safety and easy concurrency that Rust offers. However, you still have the
|
|||
|
|
option to make your variables mutable. Let’s explore how and why Rust
|
|||
|
|
encourages you to favor immutability and why sometimes you might want to opt
|
|||
|
|
out.
|
|||
|
|
|
|||
|
|
When a variable is immutable, once a value is bound to a name, you can’t change
|
|||
|
|
that value. To illustrate this, let’s generate a new project called *variables*
|
|||
|
|
in your *projects* directory by using `cargo new variables`.
|
|||
|
|
|
|||
|
|
Then, in your new *variables* directory, open *src/main.rs* and replace its
|
|||
|
|
code with the following code that won’t compile just yet:
|
|||
|
|
|
|||
|
|
<span class="filename">Filename: src/main.rs</span>
|
|||
|
|
|
|||
|
|
```rust,ignore,does_not_compile
|
|||
|
|
fn main() {
|
|||
|
|
let x = 5;
|
|||
|
|
println!("The value of x is: {}", x);
|
|||
|
|
x = 6;
|
|||
|
|
println!("The value of x is: {}", x);
|
|||
|
|
}
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
Save and run the program using `cargo run`. You should receive an error
|
|||
|
|
message, as shown in this output:
|
|||
|
|
|
|||
|
|
```text
|
|||
|
|
error[E0384]: cannot assign twice to immutable variable `x`
|
|||
|
|
--> src/main.rs:4:5
|
|||
|
|
|
|
|||
|
|
2 | let x = 5;
|
|||
|
|
| - first assignment to `x`
|
|||
|
|
3 | println!("The value of x is: {}", x);
|
|||
|
|
4 | x = 6;
|
|||
|
|
| ^^^^^ cannot assign twice to immutable variable
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
This example shows how the compiler helps you find errors in your programs.
|
|||
|
|
Even though compiler errors can be frustrating, they only mean your program
|
|||
|
|
isn’t safely doing what you want it to do yet; they do *not* mean that you’re
|
|||
|
|
not a good programmer! Experienced Rustaceans still get compiler errors.
|
|||
|
|
|
|||
|
|
The error indicates that the cause of the error is that you `cannot assign twice
|
|||
|
|
to immutable variable x`, because you tried to assign a second value to the
|
|||
|
|
immutable `x` variable.
|
|||
|
|
|
|||
|
|
It’s important that we get compile-time errors when we attempt to change a
|
|||
|
|
value that we previously designated as immutable because this very situation
|
|||
|
|
can lead to bugs. If one part of our code operates on the assumption that a
|
|||
|
|
value will never change and another part of our code changes that value, it’s
|
|||
|
|
possible that the first part of the code won’t do what it was designed to do.
|
|||
|
|
The cause of this kind of bug can be difficult to track down after the fact,
|
|||
|
|
especially when the second piece of code changes the value only *sometimes*.
|
|||
|
|
|
|||
|
|
In Rust, the compiler guarantees that when you state that a value won’t change,
|
|||
|
|
it really won’t change. That means that when you’re reading and writing code,
|
|||
|
|
you don’t have to keep track of how and where a value might change. Your code
|
|||
|
|
is thus easier to reason through.
|
|||
|
|
|
|||
|
|
But mutability can be very useful. Variables are immutable only by default; as
|
|||
|
|
you did in Chapter 2, you can make them mutable by adding `mut` in front of the
|
|||
|
|
variable name. In addition to allowing this value to change, `mut` conveys
|
|||
|
|
intent to future readers of the code by indicating that other parts of the code
|
|||
|
|
will be changing this variable value.
|
|||
|
|
|
|||
|
|
For example, let’s change *src/main.rs* to the following:
|
|||
|
|
|
|||
|
|
<span class="filename">Filename: src/main.rs</span>
|
|||
|
|
|
|||
|
|
```rust
|
|||
|
|
fn main() {
|
|||
|
|
let mut x = 5;
|
|||
|
|
println!("The value of x is: {}", x);
|
|||
|
|
x = 6;
|
|||
|
|
println!("The value of x is: {}", x);
|
|||
|
|
}
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
When we run the program now, we get this:
|
|||
|
|
|
|||
|
|
```text
|
|||
|
|
$ cargo run
|
|||
|
|
Compiling variables v0.1.0 (file:///projects/variables)
|
|||
|
|
Finished dev [unoptimized + debuginfo] target(s) in 0.30 secs
|
|||
|
|
Running `target/debug/variables`
|
|||
|
|
The value of x is: 5
|
|||
|
|
The value of x is: 6
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
We’re allowed to change the value that `x` binds to from `5` to `6` when `mut`
|
|||
|
|
is used. In some cases, you’ll want to make a variable mutable because it makes
|
|||
|
|
the code more convenient to write than if it had only immutable variables.
|
|||
|
|
|
|||
|
|
There are multiple trade-offs to consider in addition to the prevention of
|
|||
|
|
bugs. For example, in cases where you’re using large data structures, mutating
|
|||
|
|
an instance in place may be faster than copying and returning newly allocated
|
|||
|
|
instances. With smaller data structures, creating new instances and writing in
|
|||
|
|
a more functional programming style may be easier to think through, so lower
|
|||
|
|
performance might be a worthwhile penalty for gaining that clarity.
|
|||
|
|
|
|||
|
|
### Differences Between Variables and Constants
|
|||
|
|
|
|||
|
|
Being unable to change the value of a variable might have reminded you of
|
|||
|
|
another programming concept that most other languages have: *constants*. Like
|
|||
|
|
immutable variables, constants are values that are bound to a name and are not
|
|||
|
|
allowed to change, but there are a few differences between constants and
|
|||
|
|
variables.
|
|||
|
|
|
|||
|
|
First, you aren’t allowed to use `mut` with constants. Constants aren’t just
|
|||
|
|
immutable by default—they’re always immutable.
|
|||
|
|
|
|||
|
|
You declare constants using the `const` keyword instead of the `let` keyword,
|
|||
|
|
and the type of the value *must* be annotated. We’re about to cover types and
|
|||
|
|
type annotations in the next section, “Data Types,” so don’t worry about the
|
|||
|
|
details right now. Just know that you must always annotate the type.
|
|||
|
|
|
|||
|
|
Constants can be declared in any scope, including the global scope, which makes
|
|||
|
|
them useful for values that many parts of code need to know about.
|
|||
|
|
|
|||
|
|
The last difference is that constants may be set only to a constant expression,
|
|||
|
|
not the result of a function call or any other value that could only be
|
|||
|
|
computed at runtime.
|
|||
|
|
|
|||
|
|
Here’s an example of a constant declaration where the constant’s name is
|
|||
|
|
`MAX_POINTS` and its value is set to 100,000. (Rust’s constant naming
|
|||
|
|
convention is to use all uppercase with underscores between words,
|
|||
|
|
and underscores can be inserted in numeric literals to improve readability):
|
|||
|
|
|
|||
|
|
```rust
|
|||
|
|
const MAX_POINTS: u32 = 100_000;
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
Constants are valid for the entire time a program runs, within the scope they
|
|||
|
|
were declared in, making them a useful choice for values in your application
|
|||
|
|
domain that multiple parts of the program might need to know about, such as the
|
|||
|
|
maximum number of points any player of a game is allowed to earn or the speed
|
|||
|
|
of light.
|
|||
|
|
|
|||
|
|
Naming hardcoded values used throughout your program as constants is useful in
|
|||
|
|
conveying the meaning of that value to future maintainers of the code. It also
|
|||
|
|
helps to have only one place in your code you would need to change if the
|
|||
|
|
hardcoded value needed to be updated in the future.
|
|||
|
|
|
|||
|
|
### Shadowing
|
|||
|
|
|
|||
|
|
As you saw in the “Comparing the Guess to the Secret Number” section in Chapter
|
|||
|
|
2, you can declare a new variable with the same name as a previous variable,
|
|||
|
|
and the new variable shadows the previous variable. Rustaceans say that the
|
|||
|
|
first variable is *shadowed* by the second, which means that the second
|
|||
|
|
variable’s value is what appears when the variable is used. We can shadow a
|
|||
|
|
variable by using the same variable’s name and repeating the use of the `let`
|
|||
|
|
keyword as follows:
|
|||
|
|
|
|||
|
|
<span class="filename">Filename: src/main.rs</span>
|
|||
|
|
|
|||
|
|
```rust
|
|||
|
|
fn main() {
|
|||
|
|
let x = 5;
|
|||
|
|
|
|||
|
|
let x = x + 1;
|
|||
|
|
|
|||
|
|
let x = x * 2;
|
|||
|
|
|
|||
|
|
println!("The value of x is: {}", x);
|
|||
|
|
}
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
This program first binds `x` to a value of `5`. Then it shadows `x` by
|
|||
|
|
repeating `let x =`, taking the original value and adding `1` so the value of
|
|||
|
|
`x` is then `6`. The third `let` statement also shadows `x`, multiplying the
|
|||
|
|
previous value by `2` to give `x` a final value of `12`. When we run this
|
|||
|
|
program, it will output the following:
|
|||
|
|
|
|||
|
|
```text
|
|||
|
|
$ cargo run
|
|||
|
|
Compiling variables v0.1.0 (file:///projects/variables)
|
|||
|
|
Finished dev [unoptimized + debuginfo] target(s) in 0.31 secs
|
|||
|
|
Running `target/debug/variables`
|
|||
|
|
The value of x is: 12
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
Shadowing is different than marking a variable as `mut`, because we’ll get a
|
|||
|
|
compile-time error if we accidentally try to reassign to this variable without
|
|||
|
|
using the `let` keyword. By using `let`, we can perform a few transformations
|
|||
|
|
on a value but have the variable be immutable after those transformations have
|
|||
|
|
been completed.
|
|||
|
|
|
|||
|
|
The other difference between `mut` and shadowing is that because we’re
|
|||
|
|
effectively creating a new variable when we use the `let` keyword again, we can
|
|||
|
|
change the type of the value but reuse the same name. For example, say our
|
|||
|
|
program asks a user to show how many spaces they want between some text by
|
|||
|
|
inputting space characters, but we really want to store that input as a number:
|
|||
|
|
|
|||
|
|
```rust
|
|||
|
|
let spaces = " ";
|
|||
|
|
let spaces = spaces.len();
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
This construct is allowed because the first `spaces` variable is a string type
|
|||
|
|
and the second `spaces` variable, which is a brand-new variable that happens to
|
|||
|
|
have the same name as the first one, is a number type. Shadowing thus spares us
|
|||
|
|
from having to come up with different names, such as `spaces_str` and
|
|||
|
|
`spaces_num`; instead, we can reuse the simpler `spaces` name. However, if we
|
|||
|
|
try to use `mut` for this, as shown here, we’ll get a compile-time error:
|
|||
|
|
|
|||
|
|
```rust,ignore,does_not_compile
|
|||
|
|
let mut spaces = " ";
|
|||
|
|
spaces = spaces.len();
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
The error says we’re not allowed to mutate a variable’s type:
|
|||
|
|
|
|||
|
|
```text
|
|||
|
|
error[E0308]: mismatched types
|
|||
|
|
--> src/main.rs:3:14
|
|||
|
|
|
|
|||
|
|
3 | spaces = spaces.len();
|
|||
|
|
| ^^^^^^^^^^^^ expected &str, found usize
|
|||
|
|
|
|
|||
|
|
= note: expected type `&str`
|
|||
|
|
found type `usize`
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
Now that we’ve explored how variables work, let’s look at more data types they
|
|||
|
|
can have.
|