[valorzard]

Something I don’t get.

Odin doesn’t support closures (a la C++ or Rust)

The thing is, I don’t understand why.

Odin’s FAQ says it’s because closures require automatic memory management. [0] But if that’s the case, why do languages like C++ and Ada [1] support closures?

[0] https://odin-lang.org/docs/faq/#does-odin-have-closures

[1] https://learn.adacore.com/courses/advanced-ada/parts/resourc...

[wk_end]

I can't speak for Ada, but C++ closures require that you explicitly specify what's captured from the enclosing environment and how (i.e. copy or reference). That capture is also unsafe, which relates to the issue of automatic memory management: for instance, if you have a function that returns a closure that's captured a reference to something in the function's stack frame, stack semantics mean that value will be destroyed. I'm sure C++ developers are fine with them but - having not used them in anger - they sound quite brittle.

The answer in the Odin FAQ maybe could be expanded to say "many uses of closures require automatic memory management, and while Odin could add some kind of support for closures to handle the uses that don't, it'd add too much complexity and too much potential for bugs to be worthwhile". Not to speak for gingerbill, here.

[doug-moen]

what ginger bill actually said was

> I’d argue that actual closures which are unified everywhere as a single procedure type with non-capturing procedure values require some form of automatic-memory-management. That does not necessarily garbage collection nor ARC, but it could be something akin to RAII. This is all still automatic and against the philosophy of Odin.

C++ doesn't have this feature either. A C++ closure does not have the same type as a regular C-style function with the same argument types and result type. The types of functions and closures are not unified.

And C++ does have RAII, which the author feels is a kind of automatic memory management and against the philosophy of Odin.

So C++ doesn't have the feature G.B. says is impossible. I don't know enough to comment on Ada.

[tialaramex]

What Bill wrote, on his own web site, about his own language is simply this:

> For closures to work correctly would require a form of automatic memory management which will never be implemented into Odin.

I suppose you can insist Bill thinks "correctly" means all that verbiage about unified types - but then a reasonable question would be why doesn't Odin provide these "not correct" closures people enjoy in other languages ?

RAII is entirely irrelevant, the disposal of a closure over a Goose is the same as disposal of a Goose value itself. In practice I expect a language like Odin would prefer to close over references, but again Odin is able to dispose of references so what's the problem?

[kibwen]

Rust shows that closures don't require automatic memory management, unless you consider Rust's static ownership analysis to be "automatic memory management", which I suppose you could, but it's all at compile-time, not runtime. Of course, it's fair if he doesn't want his language to have an ownership system, but ownership systems honestly aren't very complex, they're just different.

[bbkane]

You really don't think ownership systems are that complex kibwen?

I just watched a recent Polonius talk ( https://m.youtube.com/watch?v=uCN_LRcswts ) and came away very impressed with the difficulty of implementing (or even modeling) the borrow checker. Or maybe you're referring to something else?

[kibwen]

Ownership and the borrow checker two distinct things; putting these concepts together is the premier novelty of Rust. "Ownership" is this: an analysis pass that enforces single-ownership of values (call it "affine types" if you want to be fancy, but it's an extremely simple analysis), along with a mechanism to allow types to opt-out of single-ownership and allow multiple ownership/implicit copying (what Rust calls the `Copy` trait). That's all it is, and it automatically gives you Rust's trick of "automatic static memory management". It's much simpler than a borrow checker, which would also require a notion of generics and subtyping, to say nothing of lifetimes (or a control flow graph, which is what you want if you want a good borrow checker). Such a system of ownership without a borrow checker could even be memory-safe, if your language doesn't allow unmanaged pointers (though it wouldn't be as efficient as Rust, and would involve more copying, and makes for slightly more annoying APIs).

[bbkane]

Would this simple system efficiently allow for larger data structures to be referenced instead of copied?

[kibwen]

References are the purview of the borrow checker, naturally, but (assuming that you care about memory safety) you might be able to get away with a system that doesn't let you store arbitrary references, but conceivably you could have some kind of simple-ish scope-based analysis that might allow the compiler to transparently elide copies when passing owned values to functions deeper in the call stack. A mechanism to reify the notion of strictly-scoped values in the language (like Python's `with` statement) could probably go quite far here, allowing your compiler to know that a piece of data is anchored to a given scope which strictly outlives some child scopes, allowing a reference to that data to remain valid for those child scopes. You'd still have to have Rust's notion of aliasing XOR mutation, but if references are first-class values this might be tractable, because you get much of this for free from an ownership system (mutable references are owned, immutable references are copyable), although Rust has several other ways that it bends over backwards to make this work nicely (e.g. compiler-inserted reborrowing). If you wanted to avoid this complexity you could start by just sticking to only having immutable references that allow copying the inner data if you want to mutate it.

[bbkane]

Sounds interesting - I'm not entirely convinced it would work, but I'm certainly less of an expert than you on this :D

[randomstringxyz]

Conceptually, think about it. Coroutines require copying not only the variables but the function itself, outside of the lifetime of the parent function. (Or at least pointers thereto.) I would like to hear about a language with static coroutines but I am not aware of any. Even Rust doesn't do it, they just make you pass the lifetime around.

[kibwen]

The parent is talking about closures, not coroutines. Rust does have closures that don't require a GC or passing lifetimes around (there's not even any syntax for putting a lifetime on a closure).

[thayne]

Rust closures can have lifetimes, and the lifetime of a closure is restricted to the lifetime of the shortest lived reference that it captures. But that just means the compiler protects you from having dangling pointers in your closure. And I don't think you can get much better than that without a runtime garbage collector.

[kibwen]

A Rust closure "has" a lifetime in the sense that the anonymous underlying struct that Rust creates to hold the closed-over values has a lifetime, but that's not a requirement to have closures without a GC. Like C++, Odin doesn't care about being memory-safe, so you can just say "be careful doing anything that involves pointers" (which is how the language already works), or if you wanted to be a little safer you could just forbid closing over anything that contained a pointer.

[csb6]

Automatic memory management isn’t necessary for closures, but if you don’t have it then it is easy to have dangling pointers (e.g. you capture a local variable by reference, return the closure object, and then call the closure and use the referenced variable). This is a problem in C++ but isn’t in Ada due to Ada’s stricter scoping rules. Capturing variables by value is safe (assuming the captured values contain no dangling references themselves). It might require allocation if there were type-erased function objects (like std::function in C++), but this could be done using explicit allocator and deallocator functions with some help from the compiler to determine the closure object’s size.