[flipgimble]

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/

[do_not_redeem]

Nothing about lambdas requires heap allocation. See also: C++, Rust

[porridgeraisin]

If the lambda captures some value, and also outlives the current scope, then that captured value has to necessarily be heap allocated.

[noselasd]

No, (in C++) the lambda can capture the the variable by value, and the lambda itself can be passed around by value. If you capture a variable by reference or pointer that your lambda outlives, your code got a serious bug.

[gf000]

And in Rust, it will enforce correct usage via the borrow checker - the outlive case simply will not compile.

If you do want it, you have the option to, say, heap allocate.

[do_not_redeem]

That would be a bug, so just... don't do that?

If you return a pointer to a local variable that outlives the scope, the pointer would be dangling. Does that mean we should ban pointers?

If you close over a pointer to a local variable that outlives the scope, the closure would be dangling. Does that mean we should ban closures?