4 ms·

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

majewsky 4y ago
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();
- shakow 4y ago
  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();
- arp242 4y ago
  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.
  - sivizius 4y ago
    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();
    - satvikpendem 4y ago
      The above seems more like valid TypeScript instead.
brundolf 4y ago
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
- Already__Taken 4y ago
  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.

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();

shakow 4y ago
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();
arp242 4y ago
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.
- sivizius 4y ago
  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();
  - satvikpendem 4y ago
    The above seems more like valid TypeScript instead.

brundolf 4y ago

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

Already__Taken 4y ago
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.