Windows -编程-变量和可变性

Windows -编程-变量和可变性
默认情况下变量是不可变的。这是 Rust 为您提供的众多推动之一，您可以利用 Rust 提供的安全性和简单的并发性来编写代码。但是，您仍然可以选择使变量可变。让我们探讨一下 Rust 如何以及为什么鼓励您支持不变性，以及为什么有时您可能想要选择退出。
当变量不可变时，一旦值绑定到名称，就无法更改该值。为了说明这一点，让我们产生一个新的项目，称为变量 在你的项目中使用目录cargo new variables。
诚接Windows驱动开发外包
然后，在您的新变量目录中，打开src/main.rs并将其代码替换为以下尚未编译的代码：
文件名：src/main.rs
fn main() {
let x = 5;
println!(“The value of x is: {}”, x);
x = 6;
println!(“The value of x is: {}”, x);
}
使用 保存并运行程序cargo run。您应该会收到一条错误消息，如下面的输出所示：
$ cargo run
Compiling variables v0.1.0 (file:///projects/variables)
error[E0384]: cannot assign twice to immutable variable x --> src/main.rs:4:5
|
2 | let x = 5;
| -
| |
| first assignment to x
| help: make this binding mutable: mut x
3 | println!(“The value of x is: {}”, x);
4 | x = 6;
| ^^^^^ cannot assign twice to immutable variable
error: aborting due to previous error
For more information about this error, try rustc --explain E0384.
error: could not compile variables
To learn more, run the command again with --verbose.
此示例显示编译器如何帮助您查找程序中的错误。尽管编译器错误可能令人沮丧，但它们仅意味着您的程序还没有安全地执行您希望它执行的操作；他们并不意味着你不是一个好的程序员！有经验的 Rustaceans 仍然会遇到编译器错误。
错误消息表明错误的原因是您cannot assign twice to immutable variable x，因为您尝试为不可变x变量分配第二个值。
当我们尝试更改我们之前指定为不可变的值时，我们会遇到编译时错误，这一点很重要，因为这种情况会导致错误。如果我们的代码的一部分基于值永远不会改变的假设而运行，而我们代码的另一部分更改了该值，则代码的第一部分可能不会执行其设计的目的。这种错误的原因事后很难追查，尤其是当第二段代码只是偶尔更改值时。
在 Rust 中，编译器保证当你声明一个值不会改变时，它真的不会改变。这意味着当您阅读和编写代码时，您不必跟踪值可能发生变化的方式和位置。因此，您的代码更容易推理。
但是可变性非常有用。变量仅在默认情况下是不可变的；正如你在第 2 章所做的那样，你可以通过mut在变量名前面添加来使它们可变。除了允许更改此值之外，还mut通过指示代码的其他部分将更改此变量的值来向代码的未来读者传达意图。
例如，让我们将src/main.rs更改为以下内容：
文件名：src/main.rs
fn main() {
let mut x = 5;
println!(“The value of x is: {}”, x);
x = 6;
println!(“The value of x is: {}”, x);
}
当我们现在运行程序时，我们得到：
$ cargo run
Compiling variables v0.1.0 (file:///projects/variables)
Finished dev [unoptimized + debuginfo] target(s) in 0.30s
Running target/debug/variables
The value of x is: 5
The value of x is: 6
我们可以更改x绑定到 from5到6whenmut 使用的值。在某些情况下，您需要使变量可变，因为与只有不可变变量相比，它使代码编写起来更方便。
除了防止错误之外，还有多种权衡需要考虑。例如，在您使用大型数据结构的情况下，就地改变实例可能比复制和返回新分配的实例更快。使用较小的数据结构，创建新实例和编写更具功能性的编程风格可能更容易思考，因此降低性能可能是获得这种清晰度的一个值得的惩罚。