too-many-lists/deque/peek

[giscus[bot]]

too-many-lists/deque/peek

https://course.rs/too-many-lists/deque/peek.html

[siliangZ]

为什么说Ref的生命周期和内部引用的生命周期不一致是必须的呢？怎么理解这个呢？是因为可能存在多个Ref对同一个内部引用的包裹，所以要将他们的生命周期分离吗？

[wangzongxu]

这样的话，为啥使用Ref::map之后就可以获得&T了呢？

[einQimiaozi]

@wangzongxu 官方文档的回答是这样的
'''
Makes a new Ref for a component of the borrowed data.
'''
我的理解是Ref::map之后也没办法活的&T，所以方法的返回必须是Ref类型而不是&T
一个新的Ref一起被返回到方法外，这样Ref的生命周期依然和T一致

[emmettng]

Ref::map 之后得到的不只是 &T，
而是以Ref为Functor， 其中的Node 经由|node| &node.elem 得到了 &T，
因此类型上就是从 Ref<Node> -> Ref<&T>

[chaoliu719]

Ref<Node<T> -> Ref<T>

[sshelll]

@wangzongxu
map 函数签名里面指定了通过 map 函数新建的 Ref(指向原始 Ref 的某个子部分) 的生命周期和原始 Ref 一样

pub fn map<U, F>(orig: Ref<'b, T>, f: F) -> Ref<'b, U>
where
    U: ?Sized,
    F: FnOnce(&T) -> &U

[aly8246]

如果使用idea来写rust代码，在这章节会遇到一个问题

    |
106 |             Ref::map(node.borrow(), |node| &node.elem)
    |                      ^^^^^^^^^^^^^ expected struct `Ref`, found reference
    |
    = note: expected struct `Ref<'_, _>`
            found reference `&_`

其中node.borrow()的时候，idea会自动导入Borrow

use std::borrow::Borrow;//错误导入的Borrow

clion可能也会存在这个问题
这个时候删掉这个多余的use就不会报错
原因大概是rc调用了同名方法

///来自为Rc实现std::borrow::Borrow的trait
impl<T: ?Sized> borrow::Borrow<T> for Rc<T> {
    fn borrow(&self) -> &T {
        &**self
    }
}

///Rc.weak为Cell类型，而Cell类型也有这个叫borrow的方法
pub fn borrow(&self) -> Ref<'_, T> {
    self.try_borrow().expect("already mutably borrowed")
}

只要删除多余的use就可以保证使用我们现在需要的borrow

[GeniusPenguin9]

点赞，刚遇到了同样问题

[WenqingZong]

想问下，std::cell::Ref和core::cell::Ref有什么不同呢？这两个似乎都可以通过编译。

[emmettng]

https://stackoverflow.com/questions/53800450/is-there-any-disadvantage-to-referencing-modules-through-core-instead-of-std

There is no difference in the actual implementation though. If the function is provided in core, the function in std is just an reexport.

TL;DR: Use std if you have an Operating System running, else use core. There is no need to mix them.

[XieyangLy]

测试函数中的assert_eq!(&*list.peek_front().unwrap(), &3);

[XieyangLy]

assert_eq!(&*list.peek_front().unwrap(), &3);
使用了&list.peek_front().unwrap(),和&3。如果是值比较是否用list.peek_front().unwrap(), 3更好？

[sswybd]

经过测试，最终的函数签名 pub fn peek_front(&self) -> Option<Ref<T>> 也可以脱糖为
pub fn peek_front<'b>(&'b self) -> Option<Ref<'b, T>>