advance/into-types/converse

[sunface]

https://course.rs/advance/into-types/converse.html

[LIPUU]

辛苦了 这里确实挺黑暗的

[overlords]

地狱

[qyWeiqy]

看了三遍，还是头大！！！

[siu91]

<'b, 'c> 这个 ' 是什么意思？

[sunface]

额，这里内容安排有点问题，这是生命周期，见后面的章节

[yuhao00]

我感觉至少要过一遍the book，不然直接上手这本肯定是一脸懵逼（我猜的

[cleanwk]

这节突然难度加大，待我先吃个饭晚上再看一遍，作者辛苦了，看得出来这本书写的真的用心。

[sunface]

这一章节起初是在进阶里面🤣 后面出于一些考虑移动到基础里，所以难度会比其他章节高一些

[caoxiemeihao]

@sunface 我飞哥手下留情先 🥺

[Jesse-666]

前面的内容还能接受 变形记有点受不了

[BiteFoo]

我第一反应是，要拍成电视里的变形计吗？😂

[zmh1994]

从上面代码可以看出，派生 Clone 能实现的根本是 T 实现了Clone特征：where T: Clone， 因此 Container 就没有实现 Clone 特征。

这句话有点不理解，看上面的代码不是已经实现了clone方法么，为啥说没有实现Clone特征？

[LucasIcarus]

宏自动派生的实现里加了 where T: Clone 作为限制条件. 所以下面实际的 clone 方法并没有被实现到任意 Container<T> 上.

后续自行实现(不使用#[derive(Clone)]) 的代码取消了 where T: Clone 限制.

[duanyuluo]

范型有很大的学习困难，是很容易把范型参数，包括生命周期都参数化去看待，所以认为：
impl Clone for Container where T: Clone
就是给Container实现了Clone特性。
但如果把范型参数都理解为：编译阶段把范型参数或具体类型参数，编译成不同版本的代码（特例化），就好理解了。比如：
Container
=>
Container_i32(Arc_i32)
所以，
impl Clone for Container
=>
impl Clone for Container_T //编译器特例化结果1

impl Clone for Container where T: Clone
=>
impl Clone for Container_T_with_Clone //编译器特例化结果2

两个struct的名字是不一样的，自然也就没有实现Clone了。因为，实现Clone的是Container_T_with_Clone而不是Container_T

[Endermanbugzjfc]

（单例化 monomorphisation）

[Cold-Stars]

where T: Clone也是类型的一部分
派生实现是有限定条件where T: Clone，所以对Container<T:Clone>实现了Clone特性，而没有对Container实现。
改成这样就可以fn clone_containers<T:Clone>(foo: &Container, bar: &Container)

[17998384]

第一个哥们解释的还是不够通透，应该说”宏自动派生的实现里加了 where T: Clone 作为限制条件，那么宏实际的 clone仅对T实现了Clone特征的才有效“，也就是说T为i32的时候，宏派生的clone才是有效果的，但T不确定类型时，也就相当于未实现clone，所以会自动用他的引用进行clone

[jyutjyu]

难度突然上升

[zhimin-z]

impl<'a> Trait for &'a i32 {} 中的 'a是什么泛型啊？'a难道不可以使mut吗？

[zhimin-z]

是

[sunface]

生命周期～

[lijing-2008]

强制类型转换是真心没看懂啊，到底是谁强制转换到了谁，能不能再仔细讲讲。&i32 实现了特征 Trait， &mut i32 可以转换为 &i32，但是 &mut i32 依然无法作为 Trait 来使用。这句话怎么理解。

[sunface]

好的，建议收到～～谢谢哈

[dongzl]

哈哈好难！是因为太难了吗？练习题都没安排~

[sunface]

练习题有的，链接没放上去

[guopenghui]

根据我的实验，.运算符的匹配过程是这样的：
a.foo() 假设a: T

1. 首先，foo方法必须有一个self参数，才可能被匹配到
2. 尝试使用值方法调用，即找self参数类型与a相同的函数foo
   • 首先看如果a是引用类型(&或&mut，其他实现Deref的不算)，则先尝试调用<*T>::foo(a)
   • 尝试调用T::foo(a)
3. 尝试使用引用方法调用：给a加一个引用，比如&a:&T，尝试调用：
   • <*&T>::foo(&a)，即T::foo(&a)
   • <&T>::foo(&a)，即<&T>::foo(&a)
4. 尝试解引用方法调用。得到解引用类型，然后回到第1步开始尝试。直到找到匹配解引用类型或无法再解引用。
5. 尝试将定长类型转换为不定长类型来查找方法，如将[i32;3](数组)转为[i32](切片)，查找[i32]上的方法。
6. 找不到，报错。

关键的地方在于第2步的第(1)步，如果a的类型是&T，其实会先去尝试调用T的方法。 而如果a是其他实现了Deref的类型T，却不会先去调用*T的方法。

[Endermanbugzjfc]

感觉 rust 编译器这么慢
除了因为有程序宏外
大部分时间都花在这些规则检查上 😅

[xyt-dev]

impl A {
fn func(&self) {println!("自动解引用的自动引用调用?")}
// fn func(self) {println!("解引用调用")} // 不可能调用, 因为behind引用不能移交所有权
}

impl Test for &A {
fn func(self) {println!("引用本身调用")}
}

感觉没这么麻烦，应该就是结构体默认调用优先级比同名的特征方法优先级高

[xuexin]

为什么b的类型改成i32会导致下面无法判断e的类型？
fn main() {
let b: i16 = 1500; //为什么改成i32会导致下面无法判断e的类型

let b_: u8 = match b.try_into() {
    Ok(b1) => b1,
    Err(e) => {
        println!("{:?}", e.to_string());
        0
    }
};

}

[duanyuluo]

把编译器错误贴出来，没理解什么叫无法判断e的类型？

[alexniver]

[Neisseri]

确实有点😢

[authorixy]

画风突变

[zhaojuncw]

麻了捏 = =！

[lovefengruoqing]

难度忽然呈指数上升，看了两遍了，还是没理解透彻

[0130w]

点操作符那一小节

若 T 不能被解引用，且 T 是一个定长类型(在编译器类型长度是已知的)

这里应该是笔误，编译期类型:D

[sunface]

好的。。已经修改，感谢

[zhangboqi]

这。。这。。这。。。还能学下去吗？

[Garker]

我听劝 这章节不学了

[sinopec]

二刷了，感觉这里居然能看懂了，记得之前看到这一块是一塌糊涂的，也不知道是作者改进表述了还是我真的开悟了。。。

[yxxuweb]

”首先也是最重要的，转换后创建一个任意类型的实例会造成无法想象的混乱，而且根本无法预测。不要把 3 转换成 bool 类型，就算你根本不会去使用该 bool 类型，也不要去这样转换。 “
莫名其妙的就出“不要把 3 转换成 bool 类型，就算你根本不会去使用该 bool 类型，也不要去这样转换。 ”很突兀。

[3517277]

我们先来推导一番。 首先通过值方法调用就不再可行，因为 T 没有实现 Clone 特征，也就无法调用 T 的 clone 方法。接着编译器尝试引用方法调用，此时 T 变成 &T，在这种情况下， clone 方法的签名如下： fn clone(&&T) -> &T，接着我们现在对 value 进行了引用。 编译器发现 &T 实现了 Clone 类型(所有的引用类型都可以被复制，因为其实就是复制一份地址)，因此可以推出 cloned 也是 &T 类型。

这里的值调用，因为value是&T类型，所以尝试值调用不是直接先从&T开始匹配吗？为什么这里说先看T呢？所谓的值调用，是看当前值的原始类型T？而不是先看当前值的实际类型&T吗？没看明白

[3517277]

我用了这个方法来测试：
'''rust
struct T{}

impl T{
fn clone(a:Self)->i32{
return 0;
}

fn do_stuff<T>(value: &T) {
    let cloned = value.clone();
}

}
'''

如果按上面说的，先调用T的值，那应该会调用我自定义的clone,应该会先返回i32类型吧？但实际上，cloned还是&T类型。

[17998384]

首先你的代码就是有问题的，定义了struct T并且在函数中又定义了泛型T，那么此时你的签名中&T实际是泛型而不是struct T，也就是说在函数中value.clone()和struct T的实现没有半毛钱关系；编译器基于&T去寻找clone方法还真找到了对应的实现，那就是标准库中的实现：

    #[stable(feature = "rust1", since = "1.0.0")]
    impl<T: ?Sized> Clone for &T {
        #[inline(always)]
        #[rustc_diagnostic_item = "noop_method_clone"]
        fn clone(&self) -> Self {
            *self
        }
    }

于是基于这个方法中的clone，因为是&self，所以基于&T那就是&&T，而返回值为*self那就是&T，所以最终结果为&T

[17998384]

而我上述发的代码对应的就是作者所说的”编译器发现 &T 实现了 Clone 类型.....“

[bettersemut]

有些复杂，感觉短暂的未来应该不会用到这么深的知识，以后有需要再来查阅

[cy-arctique]

点操作符小节那里: 从上面代码可以看出，派生 Clone 能实现的根本是 T 实现了Clone特征：where T: Clone， 因此 Container<T> 就没有实现 Clone 特征.

Container<i32> 也没有实现Clone trait 吗?

[17998384]

很明显实现了啊，所以&Container .clone()返回的就是Container啊

[gatsby0203]

如果之前是写C语言的，特别是写嵌入式裸机程序的。Transmutes里的操作简直是家常便饭，Rust主要还是想给用的人足够的控制力吧。

[Scott169]

1.75.0版Rust，TryInto 特征是预导入的，不需要use

[rahuahua]

fn do_stuff(value: &T) {
let cloned = value.clone();
}

[yuzheng14]

derive 宏派生的 Clone 实现代码

impl<T> Clone for Container<T> where T: Clone {
    fn clone(&self) -> Self {
        Self(Arc::clone(&self.0))
    }
}

这个是在哪里看的？我点进去 derive 和 Clone 都是注释的 /* compiler built-in */

[SoraRoseous]

点操作符那里，好像在引用方法调用和值方法调用之间还有一个::foo(&value)的调用

[SoraRoseous]

<T>::foo(&value)

[justin-z0]

为什么要允许存在这么复杂的转换，这些所谓的应用场景，没有其他办法解决了吗？

[inblossoms]

Rust 点操作符 ( . ) 的“寻路之旅”

当你写 value.foo() 这样的方法调用时，Rust 编译器会像一个侦探一样，为 value 类型 (T) 寻找最匹配的 foo 方法。它的搜索策略非常智能，会尝试各种“变身”来找到那个正确的方法。

假设 value 的原始类型是 T，编译器会按以下顺序尝试：

---

第一站：精确匹配 - “你就是你要找的那个吗？”

编译器首先检查 foo 方法是否可以直接在 T 类型上被调用，也就是说，是否存在一个 impl T { fn foo(self, ...) { ... } } 或者 impl SomeTrait for T { fn foo(self, ...) { ... } } 的实现，并且 foo 方法接受的是 self（即 value 的所有权）。

• 如果找到： 太好了！直接调用 T::foo(value)。此时 value 的所有权会被移动到方法内部。
• 如果没找到/不匹配： 侦探继续往下查。

---

第二站：借用变身 - “如果我只是看看，可以吗？”

如果 foo 方法不接受 self 的所有权，而是接受 &self (不可变引用) 或 &mut self (可变引用)，那么编译器会尝试对 value 进行自动引用（Auto-referencing）。

• 编译器尝试：

  • value 是否可以变成 &T 来调用 foo？（即 <&T>::foo(value) 或 impl SomeTrait for &T { fn foo(self, ...) { ... } }）
  • value 是否可以变成 &mut T 来调用 foo？（即 <&mut T>::foo(value) 或 impl SomeTrait for &mut T { fn foo(self, ...) { ... } }）

• 如果找到： 成功匹配！编译器会自动添加 & 或 &mut。value 的所有权不会被移动，只是被借用了。

• 如果没找到/不匹配： 侦探发现这条路不通，继续找更灵活的方法。

---

第三站：层层解封 - “如果我能打开几层包裹呢？”

如果上面两步都不行，编译器会怀疑 value 可能是一个“包裹”着其他值的引用或智能指针。它会利用 Deref Trait 进行自动解引用（Auto-dereferencing）。

• 前提： T 类型必须实现了 Deref<Target = U>（以及可选的 DerefMut<Target = U>）。

• 编译器尝试： 编译器会尝试对 value 自动执行 * (解引用) 操作，得到 U 类型的值，然后从 U 类型开始，重新执行第一站和第二站的所有查找过程。这个过程可以层层递归，直到找到匹配的方法为止。

• 通俗理解： 如果 value 是 Box<String>，编译器会先尝试 Box<String> 有没有 foo。如果没有，它会解引用 Box<String> 得到 String，然后看 String 有没有 foo。如果还没有，它会再解引用 String 得到 str，然后看 str 有没有 foo。

• 如果找到： 大功告成！编译器会自动插入解引用操作。

• 如果没找到/不匹配： 侦探有点绝望了，但还有最后一招。

---

第四站：定长到不定长 - “如果我能从固定盒子变成灵活的盒子呢？”

这个步骤相对特殊，主要针对固定大小的数组 [T; N]。

• 前提： T 是一个固定长度的数组，例如 [i32; 5]。

• 编译器尝试： 编译器会尝试将这个固定长度的数组自动强制转换为它的不定长切片形式 &[T]（或 &mut [T]）。

• 通俗理解： 比如 [1, 2, 3] 这样的数组本身没有 iter() 方法，但它的切片 &[1, 2, 3] 有。编译器发现你调用 my_array.iter() 时，会自动将 my_array 变成 &my_array (引用)，然后 &my_array 会被视为 &[T]，从而找到 iter() 方法。

• 如果找到： 问题解决。

• 如果还是不行： 侦探彻底放弃。

---

第五站：最终失败 - “汝欺我甚，不干了！”

• 如果以上所有步骤都无法找到一个匹配的 foo 方法，那么编译器最终会放弃，并大声报错：“找不到方法 foo”。

[inblossoms]

对于 bar_cloned 的类型理解问题

问题核心困惑点：Arc<T> 的特殊性如何影响 #[derive(Clone)]？

1. 我们认为 Container<T> 结构体添加了 #[derive(Clone)]，直觉上它应该让 Container<T> 类型变得“可复制”，并且 clone() 方法应该返回一个拥有所有权的 Container<T> 实例。
2. 但实际观察到 bar_cloned 的类型却是 &Container<T>（一个引用）。

这背后的根源在于 Arc<T> (以及 Rc<T>) 在 Clone 行为上的特殊性，以及 Rust 方法解析的优先级。

---

Arc<T> 的 Clone：特殊的“浅拷贝”

首先，理解 Arc<T> 是解决问题的关键：

• Arc<T> 是一个引用计数智能指针，它允许多个所有者共享堆上的同一份数据 T。
• 当你调用 Arc<T> 的 clone() 方法时，它不会复制 T 实际的数据。它只是：
  1. 增加 Arc 内部的一个原子计数器。
  2. 返回一个新的 Arc<T> 智能指针，这个新指针与原来的 Arc<T> 指向同一份共享数据 T。
• 这个操作是非常廉价的，因为它只涉及增加计数和复制一个指针。
• 最重要的是，Arc<T> 的 clone() 方法不要求它所包裹的类型 T 实现了 Clone 特征。

---

Container<T> 的 #[derive(Clone)] 到底生成了什么？

当你在 struct Container<T>(Arc<T>); 上使用 #[derive(Clone)] 时，Rust 编译器会生成 impl Clone for Container<T> 的代码。这段代码会逐个字段地调用它们的 clone() 方法。

由于 Container<T> 只有一个字段 Arc<T>，所以自动生成的 impl Clone 看起来是这样的：

impl<T> Clone for Container<T> {
    fn clone(&self) -> Self { // 注意：这里的 Self 是 Container<T>，返回值是拥有所有权的！
        Self(self.0.clone()) // 这里调用的是 Arc<T> 的 clone() 方法
    }
}

关键点：

• 这个生成的 impl 块上没有 where T: Clone 这样的约束。这是因为 Arc<T>::clone() 不需要 T 是 Clone 的。
• 这意味着 Container<T> 确实实现了 Clone 特征，并且对于任何类型 T 都有效，无论 T 是否 Clone。
• 这个 clone() 方法的签名 fn clone(&self) -> Self 明确表示它返回的是一个拥有所有权的 Container<T> 实例。

---

真正的困惑点：方法解析的优先级和 Clone for &T

那么，为什么 bar_cloned 还是会变成 &Container<T> 呢？这涉及到 Rust 编译器在解析 bar.clone() 这样的方法调用时所遵循的优先级规则。

1. bar 的类型是 &Container<T>。

2. Rust 编译器会首先查找直接在 &Container<T> 这个类型上是否有 clone() 方法的实现。

3. 标准库中有一个通用的毯子实现（Blanket Implementation）：

   // 这是标准库为所有引用类型提供的通用实现：
   impl<'a, T> Clone for &'a T // 对任何引用类型 `&T` 实现 Clone
   where
       T: Clone, // 前提是 `T` (被引用的类型) 本身实现了 Clone
   {
       fn clone(&self) -> Self { // 返回的 Self 是 `&'a T`，即引用本身
           *self // 仅仅是复制引用（按位复制指针）
       }
   }

   由于 Container<T> 确实实现了 Clone（如上所述），所以 &Container<T> 就满足了 Clone for &T 这个毯子实现的要求，这意味着 &Container<T> 也被视为实现了 Clone。

4. 优先级： 当你调用 bar.clone() 时，编译器会发现：

   • 在 &Container<T> 这个类型上直接有 Clone 的实现（通过毯子实现）。
   • 在 Container<T> 这个类型上也有 Clone 的实现（通过 #[derive(Clone)]）。
   • 编译器会优先选择更直接匹配接收者类型（&Container<T>）的实现。

5. 结果： 编译器选择了 impl Clone for &Container<T> 的 clone() 方法。这个方法返回的是 Self，也就是 &Container<T>。因此，bar_cloned 的类型最终被推断为 &Container<T>。

---

如何获取拥有所有权的副本？

如果你确实想要 bar.clone() 返回一个拥有所有权的 Container<T> 实例，你必须显式地解引用 bar，告诉编译器你希望在 Container<T> 本身（而不是其引用）上调用 clone() 方法：

#[derive(Clone)]
struct Container<T>(std::sync::Arc<T>);

fn clone_containers<T: Clone>(foo: &Container<i32>, bar: &Container<T>) {
    // 原始代码：foo.clone() 会调用 Clone for &Container<i32>，返回 &Container<i32>
    let foo_cloned_ref: &Container<i32> = foo.clone();
    println!("foo_cloned_ref (reference): {:?}", foo_cloned_ref.0);

    // 原始代码：bar.clone() 会调用 Clone for &Container<T>，返回 &Container<T>
    let bar_cloned_ref: &Container<T> = bar.clone();
    println!("bar_cloned_ref (reference): {:?}", bar_cloned_ref.0);

    // ------------------------------------------------------------------
    // 如何获取拥有所有权的副本：显式解引用
    let foo_cloned_owned: Container<i32> = (*foo).clone(); // 类型是 Container<i32>
    println!("foo_cloned_owned (owned): {:?}", foo_cloned_owned.0);

    let bar_cloned_owned: Container<T> = (*bar).clone(); // 类型是 Container<T>
    println!("bar_cloned_owned (owned): {:?}", bar_cloned_owned.0);

    // 验证所有权
    let moved_owned_bar = bar_cloned_owned; // 成功移动，bar_cloned_owned 失效
    // println!("{:?}", bar_cloned_owned.0); // 编译错误：值已被移动
}

---

最终总结：

一开始的直觉“应该返回 Container<T>”是基于 #[derive(Clone)] 对 Container<T> 的作用，这个直觉本身没错。但实际结果不同，是因为：

1. Arc<T> 的特殊性： 它使得 Container<T> 能够 Clone，而无需 T 也是 Clone 的。
2. Clone for &T 的毯子实现： 这个标准库中的实现，使得任何引用（只要它指向的值是 Clone 的）自身也是 Clone 的，并且只会复制引用本身。
3. 方法解析优先级： 当你对一个引用 &X 调用 .clone() 时，Rust 会优先找到并调用 Clone for &X 的实现（如果存在），而不是解引用到 X 类型上去调用 Clone for X。