4 ms·

"Zig doesn’t have lambdas" This surprises me (as a C++ guy). I use lambdas everywhere. What's the standard way of say defining a comparator when sorting an arr

"Zig doesn’t have lambdas" This surprises me (as a C++ guy). I use lambdas everywhere. What's the standard way of say defining a comparator when sorting an array in Zig?

tux1968 1y ago
Same as C, define a named function, and pass a pointer to the sorting function.
- tsimionescu 1y ago
  And what if you need to close over some local variable?
  - flohofwoe 1y ago
    Not possible, you'll need to pass the captured variables explicitly into the 'lambda' via some sort of context parameter. And considering the memory management magic that would need to be implemented by the compiler for 'painless capture' that's probably a good thing (e.g. there would almost certainly be a hidden heap allocation required which is a big no-no in Zig).
    - nine_k 1y ago
      ...or escape analysis and lifetimes, but we already have Rust %)
    - pton_xd 1y ago
      As far as I know lambdas in C++ will not heap allocate. Basically equivalent to manually defining a struct, with all your captures, and then stack allocating it. However if you assign a lambda to a std::function, and it's large enough, then you may get a heap allocation. Making all allocations explicit is one thing I do really like about Zig.
    - andrepd 1y ago
      Why would capturing require a heap allocation? Neither Rust nor C++ do this.
      - flohofwoe 1y ago
        You need to store the captured data somewhere if the lambda is called after the outer function returns. AFAIK C++ (or rather std::function) will heap-allocate if the capture size goes above some arbitrary limit (similar to small-string optimizations in std::string). Not sure how Rust handles this case, probably through some "I can't let you do that, Dave" restrictions ;)
        steveklabnik 1y ago
        The trick is that “if”. Rust won’t ever automatically heap allocate, but if your closure does get returned to a place where the capture would be dangling, it will fail to compile. You can then choose to heap allocate it if you wish, or do something else instead. Heap allocating them is fairly rare, because most usages are in things like combinators, which have no reason to enlarge their scope like that.
        andrepd 1y ago
        But that's not a closure, a closure/lambda is not an std::function. It's its own type, basically syntactic sugar for a struct with the captures vars and operator(). Of course if you want to store it on a type-erased container like std::function then you may need to heap allocate. Rust's equivalent would be a Box<dyn Fn>.
    - tsimionescu 1y ago
      If the lambda is a value type, you can just store whatever captures you want in the fields of this type, no need for heap allocations - they'll go on the stack just like anything else. You can even ask the user to explicitly specify which variables to capture, like in C++ lambdas, to be very explicit about the size of the lambda structure.
- flohofwoe 1y ago
  Unlike C you can stamp out a specialized and typesafe sort function via generics though: https://ziglang.org/documentation/master/std/#std.sort.binarySearch https://ziglang.org/documentation/master/std/#std.sort.binar...
tapirl 1y ago
Normal function declarations. This is indeed a point which makes Zig inflexible.
- lenkite 1y ago
  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?
jmull 1y ago
You can declare an anonymous struct that has a function and reference that function inline (if you want). There's a little more syntax than a dedicated language feature, but not a lot more. What's "missing" in zig that lambda implementations normally have is capturing. In zig that's typically accomplished with a context parameter, again typically a struct.
- veber-alex 1y ago
  So basically, Zig doesn't have lambdas, but because you still need lambdas, you need to reinvent the wheel each time you need it? Why don't they just add lambdas?
  - flipgimble 1y ago
    Because to use lambdas you're asking the language to make implicit heap allocations for captured variables. Zig has a policy that all allocation and control flow are explicit and visible in the code, which you call re-inventing the wheel. Lambdas are great for convenience and productivity. Eventually they can lead to memory cycles and leaks. The side-effect is that software starts to consume gigabytes of memory and many seconds for a task that should take a tiny fraction of that. Then developers either call someone who understands memory management and profiling, or their competition writes a better version of that software that is unimaginably faster. ex. https://filepilot.tech/ https://filepilot.tech/
    - do_not_redeem 1y ago
      Nothing about lambdas requires heap allocation. See also: C++, Rust
      - porridgeraisin 1y ago
        If the lambda captures some value, and also outlives the current scope, then that captured value has to necessarily be heap allocated.

"Zig doesn’t have lambdas" This surprises me (as a C++ guy). I use lambdas everywhere. What's the standard way of say defining a comparator when sorting an array in Zig?

tux1968 1y ago

Same as C, define a named function, and pass a pointer to the sorting function.

tsimionescu 1y ago
And what if you need to close over some local variable?
- flohofwoe 1y ago
  Not possible, you'll need to pass the captured variables explicitly into the 'lambda' via some sort of context parameter. And considering the memory management magic that would need to be implemented by the compiler for 'painless capture' that's probably a good thing (e.g. there would almost certainly be a hidden heap allocation required which is a big no-no in Zig).
  - nine_k 1y ago
    ...or escape analysis and lifetimes, but we already have Rust %)
  - pton_xd 1y ago
    As far as I know lambdas in C++ will not heap allocate. Basically equivalent to manually defining a struct, with all your captures, and then stack allocating it. However if you assign a lambda to a std::function, and it's large enough, then you may get a heap allocation. Making all allocations explicit is one thing I do really like about Zig.
  - andrepd 1y ago
    Why would capturing require a heap allocation? Neither Rust nor C++ do this.
    - flohofwoe 1y ago
      You need to store the captured data somewhere if the lambda is called after the outer function returns. AFAIK C++ (or rather std::function) will heap-allocate if the capture size goes above some arbitrary limit (similar to small-string optimizations in std::string). Not sure how Rust handles this case, probably through some "I can't let you do that, Dave" restrictions ;)
      - steveklabnik 1y ago
        The trick is that “if”. Rust won’t ever automatically heap allocate, but if your closure does get returned to a place where the capture would be dangling, it will fail to compile. You can then choose to heap allocate it if you wish, or do something else instead. Heap allocating them is fairly rare, because most usages are in things like combinators, which have no reason to enlarge their scope like that.
      - andrepd 1y ago
        But that's not a closure, a closure/lambda is not an std::function. It's its own type, basically syntactic sugar for a struct with the captures vars and operator(). Of course if you want to store it on a type-erased container like std::function then you may need to heap allocate. Rust's equivalent would be a Box<dyn Fn>.
  - tsimionescu 1y ago
    If the lambda is a value type, you can just store whatever captures you want in the fields of this type, no need for heap allocations - they'll go on the stack just like anything else. You can even ask the user to explicitly specify which variables to capture, like in C++ lambdas, to be very explicit about the size of the lambda structure.
flohofwoe 1y ago
Unlike C you can stamp out a specialized and typesafe sort function via generics though: https://ziglang.org/documentation/master/std/#std.sort.binarySearch https://ziglang.org/documentation/master/std/#std.sort.binar...

tapirl 1y ago

Normal function declarations. This is indeed a point which makes Zig inflexible.

lenkite 1y ago
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?

jmull 1y ago

You can declare an anonymous struct that has a function and reference that function inline (if you want). There's a little more syntax than a dedicated language feature, but not a lot more. What's "missing" in zig that lambda implementations normally have is capturing. In zig that's typically accomplished with a context parameter, again typically a struct.

veber-alex 1y ago
So basically, Zig doesn't have lambdas, but because you still need lambdas, you need to reinvent the wheel each time you need it? Why don't they just add lambdas?
- flipgimble 1y ago
  Because to use lambdas you're asking the language to make implicit heap allocations for captured variables. Zig has a policy that all allocation and control flow are explicit and visible in the code, which you call re-inventing the wheel. Lambdas are great for convenience and productivity. Eventually they can lead to memory cycles and leaks. The side-effect is that software starts to consume gigabytes of memory and many seconds for a task that should take a tiny fraction of that. Then developers either call someone who understands memory management and profiling, or their competition writes a better version of that software that is unimaginably faster. ex. https://filepilot.tech/ https://filepilot.tech/
  - do_not_redeem 1y ago
    Nothing about lambdas requires heap allocation. See also: C++, Rust
    - porridgeraisin 1y ago
      If the lambda captures some value, and also outlives the current scope, then that captured value has to necessarily be heap allocated.