不明觉厉

感觉本帖子链里唯一有真东西的一个

不过举的例子有点小问题应该没让编译器把关吧：
1、
impl S { fn inc(mut self) -> Self { Self {f: self.f + 1} };
-->
impl S { fn inc(self) -> Self { Self {f: self.f + 1} } }
加个 mut 没用
2、
impl S { fn inc(mut& self) -> mut& Self { self.f += 1; self };
-->
impl S { fn inc(&mut self) -> &mut Self { self.f += 1; self } }
mut& 是写混乱了

符合条件一种写法是：
impl S { fn inc(&self) -> Rc<S> { Rc::new(Self { f: self.f + 1 }) } }

【 在 beep (菜Ｍ.喵星耗子) 的大作中提到: 】
: 标  题: Re: 请教个rust基本问题，Rc<RefCell<T>>有啥坏处？
: 发信站: 水木社区 (Fri Dec 10 16:46:14 2021), 站内
:
: 多谢长篇回复！
:
: : 我不懂 c++，论坛看到的，c++ 几乎能完成 rust 的全部 raii 功能，但缺少最重要的编译器的严格检查。
:
: 多解释两句，rust的raii就是从c++抄来的，Box就是unique_ptr，Rc就是shared_ptr，几乎一样。在变量生命期方面，rust就是比c++多了一个“默认move语义”，而c++默认是copy语义。这一点需要习惯。因为默认move，所以编译期rust会给你检查是否使用了已经moved变量，提前警告。
:
: : 我的建议还是 rust，但不要用 Rc，一开始写起来肯定会头疼。但从论坛反馈来看，普遍经历一段痛苦期后就习惯了。
: rust里的Rc和普遍所说的ref count可能还有点角色上的不一样。rust里面有严格的所有权检查、读写引用冲突检查，所以其他语言里有些场合，不用rc也可以，但是在rust里，为了满足所有权传递和读写引用的要求，就必须要用rc，否则就要重新设计数据结构，甚至要对功能进行删减。
:
: 举一个例子，如果想要设计这样一个api:
:
: struct S { f: i32 };
: let mut s1 = S { f: 1 };
: s1.inc().inc(); // [1] 支持先let出变量，再链式调用chain
: let s2 = (S { f: 2 }).inc().inc(); // [2] 也支持先链式调用chain再初始化变量
:
: 那么怎么设计这个inc方法呢？
:
: impl S { fn inc(mut self) -> Self { Self {f: self.f + 1} };
: 这样传所有权的话，只满足[2]，不满足[1]，因为[1]的情况下这么写 s1 就被 moved 了。
:
: impl S { fn inc(mut& self) -> mut& Self { self.f += 1; self };
: 这样传引用的话，又不满足[2]，因为返回的引用所指的self的生命期不够长。
:
: 这种时候貌似只能让inc返回一个Rc<S>，通过低成本的Rc::clone来满足这个api的设计要求。
:
: 另外，任何有环的数据结构，也是不可能使用RAII解决全部问题的，必须要引入Rc和Weak，人肉来操心，或者把整个数据结构看作一个整体，用arena的思路解决问题。
:
:
: 【 在 eGust (十年) 的大作中提到: 】
: : swift 的速度基本跟 java/go 一档的，通常情况下 java/go 换技术的原因也都是 gc，而不是速度。我不知道 EDA 是啥，只能从更一般情况的情况谈快慢
: : 跟 c++ 一档又带 gc 的选项倒也不是没有，比如 d 语言基本上是能跟 c++ 战的。但是呢，一般来说，大多数技术从走入大众视野，发展到成熟期，一般都在10年左右。d 走入大众视野时，node 和 go 还都不存在，所以它注定是永远小众了。一般 micro benchmark 都不考虑 gc 的
: : 内存管理就这样，不手动的话，一共就3种主流技术：gc、rc、raii。都是上个世纪就存在的技术，各有各的优缺点，但没有免费的午餐。
: : ...................
:
: --
:
: ※ 来源:·水木社区 mysmth.net·[FROM: 166.111.77.*]
--
修改:No1 FROM 221.216.249.*
FROM 106.121.187.*