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

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?

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/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)

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.

OK, but with generics return type first tends to becomes a monster.

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.