为什么rust parser需要fn关键字?

i30*_*817 5 rust

我一直在阅读有关生锈的博客,例如这个封闭让我想知道:

fn each<E>(t: &Tree<E>, f: &fn(&E) -> bool) {
if !f(&t.elem) {
    return;
}

for t.children.each |child| { each(child, f); }
}
Run Code Online (Sandbox Code Playgroud)

为什么不能这样:

each<E>(t: &Tree<E>, f: &(&E) -> bool) {
if !f(&t.elem) {
    return;
}

for t.children.each |child| { each(child, f); }
}
Run Code Online (Sandbox Code Playgroud)

也许我在类系统上遗漏了一些可以防止这种情况的东西.

huo*_*uon 24

它使编译器,语法高亮显示器,shell脚本和人类(即每个人)的解析变得更加复杂.

例如,with fn,foo接受一个具有两个int参数并且不返回任何内容的函数,并bar获取一个指向2 ints 元组的指针

fn foo(f: &fn(int, int)) {}
fn bar(t: &(int, int)) {}
Run Code Online (Sandbox Code Playgroud)

如果没有fn,两者的参数都会变成&(int, int),编译器就无法区分它们.当然可以提出其他规则,因此它们的编写方式不同,但这些几乎肯定没有优势fn.


cen*_*lug 5

有些fn可能看起来无关紧要,但这有一个附带的好处,即使用'grep'非常容易导航生锈代码.要找到函数'foo'的定义,你只需要grep"fn\sfoo".要查看源文件中的主要定义,只需grep"(fn | struct | trait | impl | enum | type)".

这在Rust缺乏IDE的早期阶段非常有用,并且可能在其他方面简化语法.

使语法不如C++模糊是一个主要目标,它使通用编程更容易(你不必将这么多的定义引入编译单元,按特定的顺序,正确地解析它),并且应该使未来的工具更容易.与当前C++ IDE必须处理的许多问题相比,自动插入'fn'的功能非常简单.