这些举的例子我在做题的过程中真的是深有体会，这下我终于不用怀疑自己了，哈哈

--
👇
LgnMs: 感谢，正解啊，我还以为是我学的有问题，昨天反复试验了一上午，哈哈

--
👇
Grobycn: 因为 leetcode 的题目大多数都是机器生成的，不符合 rust 的语言习惯的地方太多了。

参考 https://github.com/pretzelhammer/rust-blog/blob/master/posts/learning-rust-in-2020.md#leetcode

LeetCode generated Rust	Idiomatic Rust
tree problems represent links as Option<Rc<RefCell<Node>>>	Option<Rc<RefCell<Node>>> is overkill for tree links and Option<Box<Node>> works just as well and is much easier to work with
methods which obviously mutate self still borrow it immutably, e.g. fn insert(&self, val: i32)	methods that mutate self need to borrow it mutably, e.g. fn insert(&mut self, val: i32)
signed 32-bit integers are used for all numbers, even if the problem is undefined for negative integers, e.g. fn nth_fib(n: i32) -> i32	problems which are undefined for negative integers should use unsigned integers, e.g. fn nth_fib(n: u32) -> u32
functions always take ownership of their arguments, even if it's unnecessary, e.g. fn sum(nums: Vec<i32>) -> i32	if you don't need ownership then borrow fn sum(nums: &[i32]) -> i32
functions sometimes ignore basic error cases, e.g. for fn get_max(nums: Vec<i32>) -> i32 what i32 should be returned if nums is empty?	if a result might be undefined the return type should be wrapped in an Option, e.g. fn get_max(nums: &[i32]) -> Option<i32>

感谢，正解啊，我还以为是我学的有问题，昨天反复试验了一上午，哈哈

--
👇
Grobycn: 因为 leetcode 的题目大多数都是机器生成的，不符合 rust 的语言习惯的地方太多了。

参考 https://github.com/pretzelhammer/rust-blog/blob/master/posts/learning-rust-in-2020.md#leetcode

LeetCode generated Rust	Idiomatic Rust
tree problems represent links as Option<Rc<RefCell<Node>>>	Option<Rc<RefCell<Node>>> is overkill for tree links and Option<Box<Node>> works just as well and is much easier to work with
methods which obviously mutate self still borrow it immutably, e.g. fn insert(&self, val: i32)	methods that mutate self need to borrow it mutably, e.g. fn insert(&mut self, val: i32)
signed 32-bit integers are used for all numbers, even if the problem is undefined for negative integers, e.g. fn nth_fib(n: i32) -> i32	problems which are undefined for negative integers should use unsigned integers, e.g. fn nth_fib(n: u32) -> u32
functions always take ownership of their arguments, even if it's unnecessary, e.g. fn sum(nums: Vec<i32>) -> i32	if you don't need ownership then borrow fn sum(nums: &[i32]) -> i32
functions sometimes ignore basic error cases, e.g. for fn get_max(nums: Vec<i32>) -> i32 what i32 should be returned if nums is empty?	if a result might be undefined the return type should be wrapped in an Option, e.g. fn get_max(nums: &[i32]) -> Option<i32>

是的，我清楚这个区别，但是这个二叉树貌似也用不到多所有权和内部可变吧

--
👇
苦瓜小仔: 因为 Box 做不到多所有权或者内部可变，它只是最基础的智能指针。

我就是试了，发现把Rc、RefCell部分换成Box也完全可行。。。

--
👇
cyh0: 试一下，编译器会告诉你行不行的。

因为 leetcode 的题目大多数都是机器生成的，不符合 rust 的语言习惯的地方太多了。

参考 https://github.com/pretzelhammer/rust-blog/blob/master/posts/learning-rust-in-2020.md#leetcode

LeetCode generated Rust	Idiomatic Rust
tree problems represent links as Option<Rc<RefCell<Node>>>	Option<Rc<RefCell<Node>>> is overkill for tree links and Option<Box<Node>> works just as well and is much easier to work with
methods which obviously mutate self still borrow it immutably, e.g. fn insert(&self, val: i32)	methods that mutate self need to borrow it mutably, e.g. fn insert(&mut self, val: i32)
signed 32-bit integers are used for all numbers, even if the problem is undefined for negative integers, e.g. fn nth_fib(n: i32) -> i32	problems which are undefined for negative integers should use unsigned integers, e.g. fn nth_fib(n: u32) -> u32
functions always take ownership of their arguments, even if it's unnecessary, e.g. fn sum(nums: Vec<i32>) -> i32	if you don't need ownership then borrow fn sum(nums: &[i32]) -> i32
functions sometimes ignore basic error cases, e.g. for fn get_max(nums: Vec<i32>) -> i32 what i32 should be returned if nums is empty?	if a result might be undefined the return type should be wrapped in an Option, e.g. fn get_max(nums: &[i32]) -> Option<i32>

因为 Box 做不到多所有权或者内部可变，它只是最基础的智能指针。

试一下，编译器会告诉你行不行的。

The type Rc provides shared ownership of a value of type T