advance/lifetime/advance

[sunface]

https://course.rs/advance/lifetime/advance.html

[melertoyyang]

这章的爬坡陡度太高了，可能是基础知识还是没掌握

[Nanbert]

或者这么理解是否合理呢？&mut foo在let那里就结束它的作用域了，所以‘a就是那一句话的范围，但后面loan却在println那里又出现了，超过了该范围...，（由输入生命周期推导出输出生命周期，然后判断实际函数使用中是否符合输出生命周期）

[Kangaxx-0]

或者这么理解是否合理呢？&mut foo在let那里就结束它的作用域了，所以‘a就是那一句话的范围，但后面loan却在println那里又出现了，超过了该范围...，（由输入生命周期推导出输出生命周期，然后判断实际函数使用中是否符合输出生命周期）

事实上并没有，foo 在loan绑定后，才call了method share, 这也是为什么borrow checker会返回编译问题。

如果你微调这个demo的顺序，是不会出现问题的 -> Playground.

代码下面的总结部分说的蛮明白的，反复读几遍应该就不会困惑了

[xianfuxing]

断断续续看了好多天，慢慢消化

[small-white0-0]

@Nanbert

费解啊，之前一章说生命周期的标注不会改变引用的真实生命周期，但本章第一个例子，按大佬的解释好像就改变了。。。

我觉得第一个例子的最后一段话说得很合理：“上述代码实际上完全是正确的，但是因为生命周期系统的“粗糙实现”，导致了编译错误，目前来说，遇到这种生命周期系统不够聪明导致的编译错误，我们也没有太好的办法，只能修改代码去满足它的需求，并期待以后它会更聪明。”

我的理解就是变量作用域已经消失了，但是借用检查器认为其生命周期还存在。感觉是理论“生命周期小于等于作用域”，实际是“多数生命周期小于等于作用域”。

loan 实际是一个对于foo的第一次可变借用&mut foo的重借用。所以需要 loan =》 mfoo =》 foo, 这么一个关系，去保证借用的安全性。（这里把mutate_and_share,第一次调用时重借用的 &mut foo 取名为mfoo, 避免歧意。）所以借用检查器就认为 loan存在，即mfoo存在，mfoo导致foo无法再产生其他的借用。但是理论上来说，函数调用中的重借用在离开函数的时候就应该作用域消失了。

但是 loan =》 mfoo =》 foo这种间接的关系有存在意义。如下的代码，如果直接使用 loan =》 foo 的关系，那么在已经可变借用mfoo的情况下就出现了一个不可变借用，这个是不符合借用规则的（但是应该是有使用意义吧？）。所以为了符合借用规则，重借用的关系记录就是loan =》 mfoo =》 foo。

let mut foo = Foo;
let mfoo = &mut foo;
let loan = mfoo.mutate_and_share();
println!("{:?}",loan);

PS： 这里实际是“loan” =》 &mut *mfoo =》mfoo =》 foo 的依赖关系，但是方便阐述，简化了对于可变借用mfoo的重借用描述。
PS： 关于重借用的坑感觉还多。现在官方的手册里面也没有一个章节讲这个几乎无处不在的隐式的重借用机制。

总而言之，当前的借用检查器还不是尽善尽美的。个人理解：要么“生命周期小于等于实际作用域”理解为”多数生命周期小于等于作用域“； 要么就函数调用的重借用机制理解为“重借用的临时变量，可能由于函数的生命周期标注导致作用域延长。“

[busgo]

编译期默认会怎么同一个生命周期的

[sunface]

这章的爬坡陡度太高了，可能是基础知识还是没掌握

后面会对生命周期两个章节进行下大幅优化，目前确实存在一些问题

[0oYGZo0]

当方法的参数为可变引用时需要特别小心，一方面可能不经意传递生命周期参数给返回值，一方面可能不经意跟类型活得一样久，以上两种情况比较容易违反引用规则。也许，可以就方法的参数为可变引用时组织下相关内容。文章内容是相当好。

[MarbleGateKeeper]

最后的这个例子中的错误实在是...太反直觉了。

[guodafeng]

&*self 是为什么， 不能是&self呢

[xianfuxing]

let rr: &Point = &*r;
let rr: &Point = &r;
好像都可以

[fadedzipper]

可以把它理解成c++不能有引用的引用，它自动做了*self。但rust可以。
rust里面我想要创建一个对象的新引用，我不是创建一个引用的引用，而是用这个对象再创建一个新引用。

[fadedzipper]

上面那个同学的例子可以是因为强制声明了类型，自动推断类型的时候会显示 &&Point

[aa1ss2]

不强制声明类型也可以执行,主要是因为编译器识别出了类型执行了Deref.
编译器知道强制声明的类型是错误并作出了改正
在调试器下观察就知道
let rr: &Point = &*r;
let rr: &Point = &r;
并不相等
let rr: &Point = &*r;只是相当于复制了一个指向p的指针

[qt911025]

你是说例子1吗？

fn mutate_and_share(&mut self) -> &Self {
    &*self
}

你应该把&mut也看作是类型的一部分，把self当一般参数的格式，就是这样的：

fn mutate_and_share(self: &mut Self) -> &Self {
    &*self
}

self的类型就是自身的一个可变引用，返回值是一个不可变引用，所以要解引用再引用。
（原语法确实有迷惑性，会让人觉得是个析取赋值）

[kaixinbaba]

看前：我是新手，就是想头铁 0 0
看后：吗的，我在干嘛？

[sunface]

难道不是：什么破书😆

[xusanduo08]

看前：我想挑战下自己
看后：我当个新手吧

[Kangaxx-0]

建议加入Variance相关的知识点，目前的内容貌似没有cover这块难点

[GengYage]

附议，变性确实需要拿出来讲一讲

[Linuxdazhao]

入门感觉不需要，又会增加此文的复杂度

[giveahug]

&self &Self &*self self 啥区别啊，越看越蒙😒

[Mota-Link]

Self表示实现了该方法的类型，&Self表示该类型的引用；
self表示传入实例方法的参数名，&self是self: &Self的缩写语法糖；
（self单独作参数时，是self: Self的缩写语法糖）
&*self在例子中是对参数self: &mut Self的不可变再借用。

[aa1ss2]

&*self表示再借用,其实底层就是复制了一个指针

[duanyuluo]

可以这么理解：*self是表示self指向的内存块，&(*self)就是对这块内存再取一次地址。
let r = self;
let r = &*self;
结果都是r指向同一块内存，但是有区别的，想一下？：D

[Nakiamii]

在结构体那章说的很清楚了，&self 和 &mut self 是官方给的de- sugar。
&self 等价与 self: &Self
&mut self 等价与 self：&mut Self

[qt911025]

*self是对self（self的类型是&mut Self）解引用的意思，&*self就是&(*self)
解引和创建引用都是对右边的操作，所以像&*&**a这种优先级是&(*(&(*(*a))))
解引用仍是借用，不会获得所有权。
对引用取成员的操作隐式调用了解引，解到没引用。
同时取得的成员也是一个已解引的引用（是否可变取决于正主是否可变）

[ChestnutYueyue]

无语感觉自己在看天书了。。。太玄幻了

[sunface]

抱歉，可能写得不够通俗易懂 🤣

[compdzwio]

已经很通俗易懂了。

[SuanCaiYv]

写的很通俗易懂！飞哥🐂🍺

[wuyuz]

大佬，针对例2的情况怎么解决那？
fn get_default<'m, K, V>(map: &'m mut HashMap<K, V>, key: K) -> &'m mut V
where
K: Clone + Eq + Hash,
V: Default,
{
match map.get_mut(&key) {
Some(value) => value,
None => {
map.insert(key.clone(), V::default());
map.get_mut(&key).unwrap()
}
}
}

[kiko-Y]

fn get_default<'m, K, V>(map: &'m mut HashMap<K, V>, key: K) -> &'m mut V
where K: Eq + Hash + Clone, 
      V: Default {
    if let None = map.get_mut(&key) {
        map.insert(key.clone(), V::default());
    };
    map.get_mut(&key).unwrap()
}

这样也能过

[tmtbe]

match map.get_mut(&key) {
            Some(_) => map.get_mut(&key).unwrap(),
            None => {
                map.insert(key.clone(), V::default());
                map.get_mut(&key).unwrap()
            }
        }

这样可以过，主要是不能在Some里拿到value直接返回。
我们把原本的代码改一下，不用match，改成这样，依旧是错误的：

let a = map.get_mut(&key);
        if let Some(value) = a {
            value
        }else{
            map.insert(key.clone(), V::default());
            map.get_mut(&key).unwrap()
        }

但是改造成这样又是对的：

        let a = map.get_mut(&key);
        if let Some(_) = a {
            map.get_mut(&key).unwrap()
        } else {
            map.insert(key.clone(), V::default());
            map.get_mut(&key).unwrap()
        }

我们再换一种写法：

        let a = map.get_mut(&key);
        if a.is_some(){
            a.unwrap()
        }else{
            map.insert(key.clone(), V::default());
            map.get_mut(&key).unwrap()
        }

这种写法依旧报错，改成如下又是可以的：

        let a = map.get_mut(&key);
        if a.is_some() {
            map.get_mut(&key).unwrap()
        } else {
            map.insert(key.clone(), V::default());
            map.get_mut(&key).unwrap()
        }

本质上就是你不能将map.get_mut(&key)赋值给一个生命周期很长的临时变量，虽然a在if的第二个分支没再使用了，但对于编译器来说不会考虑if的分支，而是一直到最后

        let a = map.get_mut(&key);
        if a.is_some() {
            let b=map.get_mut(&key);
            b.unwrap()
        } else {
            map.insert(key.clone(), V::default());
            map.get_mut(&key).unwrap()
        }

上面这种b生命周期很短，所以没有关系，是可以编译通过的

[z-yn]

初学Rust不到一周的菜鸟，可能是我理解不到位。

示例2的错误根源还是因为函数返回的生命周期设计，因为你返回了这个变量，那么按照生命周期语义

 fn get_default<'m, K, V>(map: &'m mut HashMap<K, V>, key: K) -> &'m mut V

返回值的生命周期至少跟map参数的生命周期一样长。 此时如果你将函数内的变量返回。则相当于函数内的变量绑定了返回值，那函数内这个变量无论是声明到哪里。都会认为至少比map参数的生命周期一样长，所以导致了之后的map一直处于借用状态。所以,即使是下面代码也是无法编译通过的。

if true {
        let option = map.get_mut(&key);
        if option.is_some() {
            return option.unwrap();
        }
    }
    map.insert(key.clone(), V::default());
    map.get_mut(&key).unwrap()

[suncunqian]

fn main() {
    use std::collections::HashMap;
    use std::hash::Hash;
    fn get_default<K, V>(map: & mut HashMap<K, V>, key: K) -> & mut V
    where
        K: Clone + Eq + Hash,
        V: Default,
    {
        // match map.get_mut(&key) {
        //     Some(value) => value,
        //     None => {
        //         map.insert(key.clone(), V::default());
        //         map.get_mut(&key).unwrap()
        //     }
        // }
        map.entry(key).or_insert(V::default())
    }
}

[zcjie1]

关于if分支的问题：我认为是CPU在处理分支时，其实是两个分支同时开始执行，再判断条件是否成立，继而选择正确的分支继续执行。
所以，可以把分支（if分支，或match分支）看做是并行处理的代码，就可以理解为什么不能编译了

[Johannnnn506]

关于再借用

fn main() {
    let mut p = Point { x: 0, y: 0 };
    let r = &mut p;

    let rr: &mut Point = &mut *r;
    rr.move_to(2, 3);
    println!("{:?}", rr);

    let rrr: &mut Point = &mut *rr;
    rrr.move_to(3, 4);
    println!("{:?}", rrr);

    println!("{:?}", r);
}

这是可以运行的。

我理解是：
这里就是用了一个安全的方式给变量起别名，因为它们本质上都是对p的可变借用。只是它们的生命周期都必须比被自己起别名的变量短，在它们各自的生命周期里面其实都是同样的一个指针，只是在这一段我们叫它r，另一段我们叫它rr...
当然这样的话，只有最开始的借用的才有真实的借用过程，显然不可以开始不可变借用然后二次借用采用可变借用。而初次借用的是可变的，二次借用无论可变或者是不可变都可以，因为其实是一个东西。

理解的对吗？

[Johannnnn506]

同意。
再考虑了一下感觉这个概念主要只是告诉我们在调用函数传参的时候实际机制是什么，就是在传参的时候发生了一次再借用来确保函数结束不会drop掉原先的引用。这么一想还挺优雅的。
似乎也没有什么别的必须要用到这个概念的地方了？

[Mota-Link]

不只是函数传参噢，所有将可变引用赋值给位置的行为，都可能发生再借用，前提是要先明确变量的类型。例如：

    let x = &mut 0_i32; // Move：因为x的类型未知，需要推导
    let y: &mut i32 = x; // Reborrow：y的类型已知

这个现象是因为再借用需要根据目标类型，判断再借用为& *T还是&mut *T。

[Johannnnn506]

感谢回复！
关了rust-analyzer尝试了几种写法才明白你的意思。Interesting...

[anson0370]

探讨一下这个 thread 。

先上个例子：

#[derive(Debug)]
struct S(i32);

impl S {
    fn add(&mut self, v: i32) {
        self.0 += v;
    }
}

fn main() {
    let mut s = S(1);
    let r = &mut s;
    // let rr = r; // 这样写是不行的，这样就变成了 move 而不是 reborrow
    // let rr = &mut *r; // 这样写就行了
    let rr: &mut S = r;

    println!("{:?}", rr);
    r.add(1);
    println!("{:?}", r);
}

实际上 let rr = r; 这句开了 rust-analyzer 是能看到类型推导出来就是 &mut S ，逻辑上和下面那句 let rr: &mut S = r; 应该没有区别才对。而且 let rr = &mut *r; 也是可以的，这个时候 rr 的类型也是推导出来的。
以下是我的猜测：

• 首先我们已知 let b = a; 是 move ，let b = &a; 是 borrow 。
• 猜测类型推导发生在 move / borrow 的判断之后。
• 对于 let rr = r; 编译器作为 move 处理。
• 对于 let rr = &mut *r; 编译器作为 borrow 处理，因为右边显式出现了引用。
• 对于 let rr:&mut S = r; 编译器作为 borrow 处理，因为左边显式出现了引用。
• 编译器基于 NLL 对于 borrow 进行了优化，即为 reborrow 。而 move 不适用于 NLL ，因此报错。

那么我的问题就变成了：

1. 对引用的 move 有意义吗？如果对引用的 move 其实是无意义的，所有情况都可以适用 reborrow 来处理的话，是否 rust 编译器应该将对引用的绑定动作都当成 borrow 处理？
2. 如果确实需要区分，这在语法上的区别是不是有点太微妙了……

[aa1ss2]

其他不太清楚,毕竟小白一个,有个显而易见的意义就是性能,借用是要进行拷贝的,需要保存的空间和执行指令.而move是在编译器层级了,对性能没有影响.

[zhwei820]

多看几遍

[PigFairySpa]

rustc 1.61.0 第一个例子可以了

[zd08135]

1.62.1，还是不行

[ichsonx]

都说学rust是陡坡，感觉形容悬崖更合适。
另外请教下作者大大：个人目前看来rust的coding难度还是比较高的，开发效率应该不高吧？

[sunface]

开发效率取决于多个方面。单论编码效率肯定是比不上 go、python 的，但是熟练后不算低 ：）

[ichsonx]

开发效率取决于多个方面。单论编码效率肯定是比不上 go、python 的，但是熟练后不算低 ：）

我也是go转过来的，go的编码确实还是挺舒服的，除了很多的if nil之外。
可否请教下，你是因什么原因转向rust呢？

[sunface]

开发效率取决于多个方面。单论编码效率肯定是比不上 go、python 的，但是熟练后不算低 ：）

我也是go转过来的，go的编码确实还是挺舒服的，除了很多的if nil之外。 可否请教下，你是因什么原因转向rust呢？

都在用。。适用场景其实不太冲突

[SifungLei]

真复杂。好难懂。

[hookover]

太难了，烧脑，结果还烧糊了

[zhangjt93]

对于这本书的定位以及平缓学习曲线的初衷来讲，这一章不是很好，尤其是第二个例子。如果不行我觉得可以删掉这一章，让初学者遇到的时候再去研究也好。

[tinnkai]

这文章过时了，好多编译器已经解决了

[guowei001]

foo.mutate_and_share()这里编译器显示就是进行了可变借用,然后foo.share()这里进行了不可变借用,所以后面再通过println!("{:?}", loan)使用可变借用失败了.不是"理论上来说它最终是进行了不可变借用",在&mut self这里就已经发生了

[AnkoGo123]

虽然我现在看懂了你的书，但是我还是不认为你的书是一本可以面向非cpp的人看的书，我拥有丰富的go开发经验，但前2年看你的书时候，还是对这些概念非常陌生，也无法得到你的真传，直到最近突然开窍，回来重新看你的书，才看懂了你表达的意思，之前看了你很多章节，朦朦胧胧的，有点懂，又好像不是很懂，似懂非懂，所以，我还是不推荐这本书作为入门书籍，无论如何，官网的书籍和rust程序设计，以及众多的公众号网文还是比你这本书浅显易懂的！不过还是非常感谢你，因为你这本书是适合已经看完“官网的书籍和rust程序设计，以及众多的公众号网文”的人，但是真的不是很适合小白或者go开发者

[glaceglace]

我沒有看明白第一個例子。假如代碼是這樣的

#[derive(Debug)]
struct Foo{
    x:i32
}

impl Foo {
    fn mutate_and_share(&mut self) -> &Self {
        self.x = 20;
        &*self
    }
    fn share(&self) {}
}

fn main() {
    let mut foo = Foo{x:10};
    let loan = foo.mutate_and_share();
    // foo.share();
    println!("{:?}", loan);
}

不能說因爲返回的是&Self所以就是不可變引用吧？因爲上面loan的值就是被修改了的。把一個&mut self傳進函數如果當成不可變引用反而會很不安全吧

[325bit]

最后一个例子并不需要写的这么麻烦，下面的代码也同样会出现这个问题，而且可以看到即使没有方法，也会出现同样的报错，说明这个报错跟impl的注解没有关系
struct borrrowstr<'a> {
content: &'a mut &'a str,
}
#[cfg(test)]
mod tests {
use super::*;
#[test]
fn lifetime_test() {
let mut a = "hello";
let x = borrrowstr { content: &mut a };
let c = &a;//->error
}
}

[restart126]

最后是看明白了，但让我自己写根本写不出来

[fishincat]

闭包的生命周期还有其他解决办法：

fn main() {
    let closure_slision: Box<dyn Fn(&i32) -> &i32> = Box::new(|x: &i32| -> &i32 { x });
    assert_eq!(*closure_slision(&45), 45);
    // Passed !
}

本质是约束闭包不能捕获引用，上述语句在编译的时候会被编译器添加上'static约束：

fn main() {
    let closure_slision: Box<dyn Fn(&i32) -> &i32 + 'static> = Box::new(|x: &i32| -> &i32 { x });
    assert_eq!(*closure_slision(&45), 45);
    // Passed !
}

这篇文章中的办法也是一样，实际是下面的形式：

fn main() {
    let closure_slision = fun(|x: &i32| -> &i32 { x });
    assert_eq!(*closure_slision(&45), 45);
    // Passed !
}

fn fun<T, F: Fn(&T) -> &T + 'static>(f: F) -> F {
    f
}

[fishincat]

第一个例子编译器的做法是对的，考虑如下代码。

use std::cell::RefCell;

struct Foo {
    x: i32,
}

impl Foo {
    fn mutate_and_share<'a: 'c, 'b, 'c>(
        &'a mut self,
        cell: &'b mut RefCell<&'c mut Foo>,
    ) -> &'b RefCell<&'c mut Foo> {
        cell.replace(self);
        cell
    }

    fn share(&self) {}

    fn modify(&mut self) {
        self.x = 2;
    }
}

fn main() {
    let mut foo1 = Foo { x: 1 };
    let mut c = RefCell::new(&mut foo1);

    let mut foo = Foo { x: 1 };
    let cell = foo.mutate_and_share(&mut c);

    // compile error:
    //      cannot borrow `foo` as immutable because it is also borrowed as mutable immutable borrow occurs here
    foo.share();

    cell.borrow_mut().modify();
}

虽然cell是不可变引用，但是它引用了foo的可变引用，若cell具有内部可变性，则对cell的不可变引用会改变foo的数据。因此编译器的做法是保守正确的。

[vince-1998]

我想挑战一下我的软肋

[vince-1998]

个人认为，作者最后一个例子出错的原因是，返回参数Interface和输入参数&'a mut self的生命周期是一样的，list用到了最后，所以返回参数Interface也活到了最后，所以Interface一直到最后到保持了对self.manager的可变引用，所以才会说可变引用和不可变引用同时存在的作用。和作者说的“而 List 的生命周期也是 'a，说明该方法至少活得跟 List 一样久”，我感觉是没有关系的

[vince-1998]

折腾了一个小时，发现自己之前理解的有误差，我重新记录一下，
impl<'a> List<'a> {
pub fn get_interface(&'a mut self) -> Interface {
Interface {
manager: &mut self.manager
}
}
}
表明，interface会和&'a mut self(即List结构体和结构体实例)的生命周期一样长，因为主函数后面还在用list实例，所以interface的生命周期还没有结束，
list.get_interface().noop();//interface还没有drop
println!("Interface should be dropped here and the borrow released");
use_list(&list);//这句之后interface才drop，但是已经同时出现可变引用和不可变引用

作者给出修改后的代码
impl<'a> List<'a> {
pub fn get_interface<'b>(&'b mut self) -> Interface<'b, 'a>
where 'a: 'b {
Interface {
manager: &mut self.manager
}
}
}

因为 'a: 'b，调用此方法的引用和interface生命周期的长度是一样的，当
list.get_interface().noop();
之行结束后，interface其实是可以死(可以比list的生命周期短)的，所以关于manager: &mut self.manager的可变引用也是可以死了的，所以不会后续的不可变引用冲突

[bcdax110]

闭包函数的消除规则那的let closure_slision = |x: &i32| -> &i32 { x };
写成
let closure_slision: Box<dyn Fn(&i32)->&i32> = Box::new(|x|{ x });可不可以？好像多了一个Box

[hamster0523]

        // 这里报错的原因是：在list.get_interface()调用之后，产生了对于list的可变借用
        // 该可变借用并没有在调用之后被释放，而是一直持续到了对于list可变借用的再次调用在use_list(&list)中
        // 可能是生命周期的标注有问题，这里对于list.get_interface()的调用,其输入只有一个&mut self参数，因此输出的Interface也具有和输入相同的生命周期参数'a
        // 之后对于Interface调用noop()函数，并没有任何的返回，因此对于输出的Interface来说已经被释放了
        // 但是这里对于list的可变借用并没有消失，get_interface()中，方法本身是个指针（同理也就是一个引用）
        // 对于方法而言，其申明的生命周期为'a, 其调用的list可变引用的生命周期也是'a,
        // 这说明：方法可以和list活得一样久，自然，对于list的可变引用也活得和list一样久
        // 因此之后产生了两次对于list的可变引用，报错

不知道对于最后一个例子的想法对不对，这里方法其实也可以看成一个引用吧（方法不就是一个指针吗，引用也是一个指针。。。。）？

[Raven824]

我理解第一个例子报错的原因在于之前在2.2.3章节中说到的：引用必须总是有效的。所以在loan这个变量存在过程中，还需要使用到&mut self，最终导致了报错。哪怕方法已经调用完成，但是借用还存在，和可变借用存在关联。这也和编译器报错内容符合。编辑器在12行报不可变借用发生在这里，13行报可变借用之后在这里使用。
error[E0502]: cannot borrow foo as immutable because it is also borrowed as mutable
--> src/main.rs:12:5
|
11 | let loan = foo.mutate_and_share();
| ---------------------- mutable borrow occurs here
12 | foo.share();
| ^^^^^^^^^^^ immutable borrow occurs here
13 | println!("{:?}", loan);
| ---- mutable borrow later used here

=============================================================================

我写了一个简化版的，内容如下，报错和上面作者的报错基本一致。

fn main() {
let mut foo = 3;

let loan = &mut foo;

println!("{:?}",foo);

println!("{:?}", loan);
}
如果把输出两行互换位置，在loan输出后从内存中删除，再输出foo就没问题了，可以两个变量都进行输出。和上面作者的代码如下两行互换后，即可不报错原理一致。
foo.share();
println!("{:?}", loan);

如有错误希望大家可以指出，非常感谢。
ps：给作者提个小建议，建议给出报错的代码后，再给下可以执行成功的，或者说明下如何修改可以运行成功，这样能让我们小白更加方便的理解。