Why does parsing rust require the fn keyword?

Question

I read blogs about rust, and this closure, for example, made me think:

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

why not:

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

I may have lost something in the class system that would have prevented this.

Answer 1

This makes the analysis more difficult for compilers, syntactic markers, shell scripts, and people (i.e. all).

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

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

Without fn arguments for both become &(int, int) , and the compiler cannot tell them apart. Of course, you can come up with other rules so that they are written in different ways, but they almost certainly have no advantages over using fn .

Answer 2

Some of fn may seem like extraneous, but it has the side advantage that the rust code is extremely easy to navigate with grep. To find the definition of the function "foo", you simply grep "fn \ sfoo". To see the basic definitions in the source file, just grep for "(fn | struct | trait | impl | enum | type)".

This is very useful at an early stage when rust does not have an IDE and probably simplifies grammar in other ways.

Making grammar less ambiguous than C ++ is the main goal, it simplifies universal programming (you don't need to enter so many definitions into the compilation unit in a certain order to parse it correctly), and this should make the future tool easier. The 'fn auto-insertion function would be quite simple compared to many of the problems that the current C ++ environment has to deal with.