Why does rust parser need the fn keyword?

Question

I've been reading the blogs about rust and this closure for example made me wonder:

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

for t.children.each |child| { each(child, f); }
}

why couldn't it be:

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

for t.children.each |child| { each(child, f); }
}

Maybe i'm missing something on the class system that would prevent this.

Answer 1

It makes parsing more complicated for compilers, syntax-highlighters, shell scripts and humans (i.e. everyone).

For example, with fn, foo takes a function that has two int arguments and returns nothing, and bar takes a pointer to a tuple of 2 ints

fn foo(f: &fn(int, int)) {}
fn bar(t: &(int, int)) {}

Without fn, the arguments for both become &(int, int) and the compiler couldn't distinguish them. Sure one could come up with other rules so they are written differently, but these almost certainly have no advantages over just using fn.