Hacker News Reader

Comment by Already__Taken | Hacker News Reader

I'm just surprised anonymous fn () { } wasn't the obvious choice for closure.

This is pretty much the closure syntax used by Go, and it's one of its biggest issues (IMHO). Even if you had map/filter/etc. methods on slices, it would still look like:

  squares := numbers.
      filter(func(x int) bool { return x >= 0 }).
      map(func(x int) int { return x * x })

With what I understand to be your suggested Rust syntax, this would still me:

  let squares: Vec<_> = numbers.iter()
      .filter(fn(x: i64) -> bool { x >= 0 })
      .map(fn(x: i64) -> i64 { x * x })
      .collect();

which is a lot of noise compared to

  let squares: Vec<_> = numbers.iter().filter(x => x >= 0).map(x => x * x).collect();

There is no reason changing only the syntax would prevent the compiler from inferring in/out types. It would be something more akin to:

      let squares: Vec<_> = numbers.iter().filter(fn(x) { x >= 0 }).map(fn(x) { x * x }).collect();

What makes the Go code so verbose isn't so much that you have to type "func()", but rather that you need to list out all the types, as well as the need for an explicit return.

  squares := numbers.
      filter(func(x) { x >= 0 }).
      map(func(x) { x * x })

  let squares: Vec<_> = numbers.iter()
      .filter(fn(x) -> { x >= 0 })
      .map(fn(x) -> { x * x })
      .collect();

You don't necessarily need new syntax for this, although it may help with clarity.

The Rust => code is still a bit shorter, but not much and I don't think it matters much.

For the record:

    let squares: Vec<_> = numbers.iter().filter(x => x >= 0).map(x => x * x).collect();

is not valid Rust, but this is:

    let squares: Vec<_> = numbers.iter().filter(|&&x| x >= 0).map(|x| x * x).collect();

The above seems more like valid TypeScript instead.

Yeah, I tend to agree. I do think it's important that the { } be optional, for single-expression lambdas, but something along these lines would've been much more readable imo if it were possible to fit into the grammar

yeh, but likewise I don't see `fn double(arg: u32) -> arg * 2` an issue if you want to contract the syntax. using multiple lines requires {} it's got nothing to do with the "type" of function. Unless function and lambda are different beasts, I'm still learning.

`|arg| arg*2` and also `|arg| { arg * 2 }` I'm not really a fan.

Reply on news.ycombinator.com