5 ms·

By adopting a syntax like fn add(x: i32, i32) i32 they have said perma-goodbye to lambdas. They should have at-least considered fn add(x: i32, i32):

By adopting a syntax like fn add(x: i32, i32) i32 they have said perma-goodbye to lambdas. They should have at-least considered fn add(x: i32, i32): i32

hinkley 1y ago
They could still fix it with arrow functions, but it’s always gonna look weird. Some other people have tried to explain how they prefer types before variable declarations, and they’ve done a decent job of it, but it’s the function return type being buried that bothers me the most. Since I read method signatures far more often than method bodies. fn i32 add(…) is always going to scan better to me.
- lenkite 1y ago
  OK, but with generics return type first tends to becomes a monster.
  - hinkley 1y ago
    I used to be very enthusiastic about generic types. Now, well what else would you do? I don’t mean that as a rhetorical question. If someone came up with another way to represent functions that can take multiple types and knows what it will return, I’d be all over them. Elixir is trying something, I don’t know yet whether it will be better. But their solution is based on a decision about how to do overloading that I suspect makes for maintenance problems later. So it’s gonna have to be good to offset the consequence.
bitwizeshift 1y ago
Why “perma goodbye”? Go has a similar function declaration, and it supports anonymous functions/lambdas. E.g. in go, an anonymous func like this could be defined as foo := func(x int, _ int) int { … } So I’d imagine in Zig it should be feasible to do something like var foo = fn(x: i32, i32) i32 { … } unless I’m missing something?
- lenkite 1y ago
  Anonymous functions aren't the same as lambda functions. People in the Go community keep asking for lambda functions and never get them. There should be no need for func/fn and explicit return. Because the arrow would break stuff is one of the reasons. See https://github.com/golang/go/issues/59122 https://github.com/golang/go/issues/59122 https://github.com/golang/go/issues/21498 https://github.com/golang/go/issues/21498 res := is.Map(func(i int)int{return i+1}).Filter(func(i int) bool { return i % 2 == 0 }). Reduce(func(a, b int) int { return a + b }) vs res := is.Map((i) => i+1).Filter((i)=>i % 2 == 0).Reduce((a,b)=>a+b)

By adopting a syntax like fn add(x: i32, i32) i32 they have said perma-goodbye to lambdas. They should have at-least considered fn add(x: i32, i32): i32

hinkley 1y ago

They could still fix it with arrow functions, but it’s always gonna look weird. Some other people have tried to explain how they prefer types before variable declarations, and they’ve done a decent job of it, but it’s the function return type being buried that bothers me the most. Since I read method signatures far more often than method bodies. fn i32 add(…) is always going to scan better to me.

lenkite 1y ago
OK, but with generics return type first tends to becomes a monster.
- hinkley 1y ago
  I used to be very enthusiastic about generic types. Now, well what else would you do? I don’t mean that as a rhetorical question. If someone came up with another way to represent functions that can take multiple types and knows what it will return, I’d be all over them. Elixir is trying something, I don’t know yet whether it will be better. But their solution is based on a decision about how to do overloading that I suspect makes for maintenance problems later. So it’s gonna have to be good to offset the consequence.

bitwizeshift 1y ago

Why “perma goodbye”? Go has a similar function declaration, and it supports anonymous functions/lambdas. E.g. in go, an anonymous func like this could be defined as foo := func(x int, _ int) int { … } So I’d imagine in Zig it should be feasible to do something like var foo = fn(x: i32, i32) i32 { … } unless I’m missing something?

lenkite 1y ago
Anonymous functions aren't the same as lambda functions. People in the Go community keep asking for lambda functions and never get them. There should be no need for func/fn and explicit return. Because the arrow would break stuff is one of the reasons. See https://github.com/golang/go/issues/59122 https://github.com/golang/go/issues/59122 https://github.com/golang/go/issues/21498 https://github.com/golang/go/issues/21498 res := is.Map(func(i int)int{return i+1}).Filter(func(i int) bool { return i % 2 == 0 }). Reduce(func(a, b int) int { return a + b }) vs res := is.Map((i) => i+1).Filter((i)=>i % 2 == 0).Reduce((a,b)=>a+b)