我一直在阅读有关 rust 的博客，例如这个关闭让我想知道：
fn each<E>(t: &Tree<E>, f: &fn(&E) -> bool) {
if !f(&t.elem) {
return;
}
for t.children.each |child| { each(child, f); }
}
为什么不能：
each<E>(t: &Tree<E>, f: &(&E) -> bool) {
if !f(&t.elem) {
return;
}
for t.children.each |child| { each(child, f); }
}
也许我在班级系统上遗漏了一些可以防止这种情况发生的东西。
【问题讨论】：
标签： rust
它使编译器、语法高亮程序、shell 脚本和人类（即所有人）的解析更加复杂。
例如，对于fn，foo 采用具有两个 int 参数且不返回任何内容的函数，而 bar 采用指向 2 个元组的指针 ints
fn foo(f: &fn(int, int)) {}
fn bar(t: &(int, int)) {}
没有fn，两者的参数都变成&(int, int)，编译器无法区分它们。当然可以提出其他规则，因此它们的编写方式不同，但几乎可以肯定，这些规则与仅使用 fn 相比没有任何优势。
【讨论】：
某些 fn 可能看起来无关紧要，但这有一个附带好处，即使用 'grep' 可以非常轻松地浏览 rust 代码。要查找函数 'foo' 的定义，只需 grep "fn\sfoo"。要查看源文件中的主要定义，只需 grep 查找“(fn|struct|trait|impl|enum|type)”。
这在 rust 缺乏 IDE 的早期阶段非常有用，并且可能确实以其他方式简化了语法。
使语法不像 C++ 那样模棱两可是一个主要目标，它使泛型编程更容易（您不必在编译单元中按特定顺序引入太多定义来正确解析它），并且应该使未来工具更容易。与当前 C++ IDE 必须处理的许多问题相比，自动插入“fn”的功能非常简单。
【讨论】：