|
|
|
@ -1,6 +1,6 @@
|
|
|
|
|
# 代码重构导致的可变借用错误
|
|
|
|
|
|
|
|
|
|
相信大家都听说过**重构一时爽,一直重构一直爽**的说法,私以为这种说法是很有道理的,不然技术团队绩效从何而来?但是,在Rust中,重构可能就不是那么爽快的事了,不信?咱们来看看。
|
|
|
|
|
相信大家都听说过**重构一时爽,一直重构一直爽**的说法,私以为这种说法是很有道理的,不然技术团队绩效从何而来?但是,在 Rust 中,重构可能就不是那么爽快的事了,不信?咱们来看看。
|
|
|
|
|
|
|
|
|
|
## 欣赏下报错
|
|
|
|
|
很多时候,错误也是一种美,但是当这种错误每天都能见到时(呕):
|
|
|
|
@ -27,12 +27,12 @@ impl Test {
|
|
|
|
|
}
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
这段代码是可以正常编译的,也许有读者会有疑问,`self`在这里被两个变量以可变的方式借用了,明明违反了Rust的所有权规则,为何它不会报错?
|
|
|
|
|
这段代码是可以正常编译的,也许有读者会有疑问,`self`在这里被两个变量以可变的方式借用了,明明违反了 Rust 的所有权规则,为何它不会报错?
|
|
|
|
|
|
|
|
|
|
答案要从很久很久之前开始(啊哒~~~由于我太啰嗦,被正义群众来了一下,那咱现在开始长话短说,直接进入主题)。
|
|
|
|
|
|
|
|
|
|
#### 正确代码为何不报错?
|
|
|
|
|
虽然从表面来看,`a`和`b`都可变引用了`self`,但是Rust的编译器在很多时候都足够聪明,它发现我们其实仅仅引用了同一个结构体中的不同字段,因此完全可以将其的借用权分离开来。
|
|
|
|
|
虽然从表面来看,`a`和`b`都可变引用了`self`,但是 Rust 的编译器在很多时候都足够聪明,它发现我们其实仅仅引用了同一个结构体中的不同字段,因此完全可以将其的借用权分离开来。
|
|
|
|
|
|
|
|
|
|
因此,虽然我们不能同时对整个结构体进行可变引用,但是我们可以分别对结构体中的不同字段进行可变引用,当然,一个字段至多也只能存在一个可变引用,这个最基本的所有权规则还是不能违反的。变量`a`引用结构体字段`a`,变量`b`引用结构体字段`b`,从底层来说,这种方式也不会造成两个可变引用指向了同一块内存。
|
|
|
|
|
|
|
|
|
@ -80,7 +80,7 @@ error[E0499]: cannot borrow `*self` as mutable more than once at a time
|
|
|
|
|
## 大聪明编译器
|
|
|
|
|
为什么?明明之前还是正确的代码,就因为放入函数中就报错了?我们先从一个简单的理解谈起,当然这个理解也是浮于表面的,等会会深入分析真实的原因。
|
|
|
|
|
|
|
|
|
|
之前讲到Rust编译器挺聪明,可以识别到引用到不同的结构体字段,因此不会报错。但是现在这种情况下,编译器又不够聪明了,一旦放入函数中,编译器将无法理解我们对`self`的使用:它仅仅用到了一个字段,而不是整个结构体。
|
|
|
|
|
之前讲到 Rust 编译器挺聪明,可以识别到引用到不同的结构体字段,因此不会报错。但是现在这种情况下,编译器又不够聪明了,一旦放入函数中,编译器将无法理解我们对`self`的使用:它仅仅用到了一个字段,而不是整个结构体。
|
|
|
|
|
|
|
|
|
|
因此它会简单的认为,这个结构体作为一个整体被可变借用了,产生两个可变引用,一个引用整个结构体,一个引用了结构体字段`b`,这两个引用存在重叠的部分,最终导致编译错误。
|
|
|
|
|
|
|
|
|
@ -111,13 +111,13 @@ fn increase(&mut self) {
|
|
|
|
|
|
|
|
|
|
为何会有这种编译器行为,主要有两个原因:
|
|
|
|
|
1. 一般来说,我们希望编译器有能力独立的编译每个函数,而无需深入到相关函数的内部实现,因为这样做会带来快得多的编译速度。
|
|
|
|
|
2. 如果没有这种保证,那么在实际项目开发中,我们会特别容易遇到各种错误。 假设我们要求编译器不仅仅关注相关函数的签名,还要深入其内部关注实现,那么由于Rust严苛的编译规则,当你修改了某个函数内部实现的代码后,可能会引起使用该函数的其它函数的各种错误!对于大型项目来说,这几乎是不可接受的!
|
|
|
|
|
2. 如果没有这种保证,那么在实际项目开发中,我们会特别容易遇到各种错误。 假设我们要求编译器不仅仅关注相关函数的签名,还要深入其内部关注实现,那么由于 Rust 严苛的编译规则,当你修改了某个函数内部实现的代码后,可能会引起使用该函数的其它函数的各种错误!对于大型项目来说,这几乎是不可接受的!
|
|
|
|
|
|
|
|
|
|
然后,我们的借用类型这么简单,编译器有没有可能针对这种场景,在现有的借用规则之外增加特殊规则?答案是否定的,由于Rust语言的设计哲学:特殊规则的加入需要慎之又慎,而我们的这种情况其实还蛮好解决的,因此编译器不会为此新增规则。
|
|
|
|
|
然后,我们的借用类型这么简单,编译器有没有可能针对这种场景,在现有的借用规则之外增加特殊规则?答案是否定的,由于 Rust 语言的设计哲学:特殊规则的加入需要慎之又慎,而我们的这种情况其实还蛮好解决的,因此编译器不会为此新增规则。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
## 解决办法
|
|
|
|
|
在深入分析中,我们提到一条重要的规则,要影响编译行为,就需要更改相关函数的签名,因此可以修改`increate_a`的签名:
|
|
|
|
|
在深入分析中,我们提到一条重要的规则,要影响编译行为,就需要更改相关函数的签名,因此可以修改`increase_a`的签名:
|
|
|
|
|
```rust
|
|
|
|
|
fn increase_a (a :&mut u32) {
|
|
|
|
|
*a += 1;
|
|
|
|
|