CODEWITHSUNDEEP
rust
i30817
i30817

Reputation: 1378

Why does rust parser need the fn keyword?

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.

Upvotes: 6

Views: 1574

Answers (2)

centaurian_slug
centaurian_slug

Reputation: 3399

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

This is extremely helpful at this early stage when rust lacks IDE's, and probably does simplify the grammar in other ways.

Making the grammar less ambiguous than C++ is a major goal , it makes generic programming easier (you dont have to bring in so much definition into a compile unit, in a specific order, to correctly parse it), and should make future tooling easier. A feature to auto-insert 'fn's would be pretty straightforward compared to many of the issues current C++ IDE's have to deal with.

Upvotes: 5

huon
huon

Reputation: 102216

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.

Upvotes: 25

Related Questions