Yes, the obvious way to do this is have the compiler add a context parameter to every function that allocates memory or dereferences a pointer (semantically). To run the program, the main function ala c initializes the context and passes it in to the actual main program implementation. When the program finishes, all the memory can just be released in bulk in the wrapper main that initialized the context.

This is actually a serious proposal for the Rust language, it's called contexts and capabilities

Here's a blog post from 2021 https://tmandry.gitlab.io/blog/posts/2021-12-21-context-capa...

This isn't implemented yet, and the proposal never matured into a proper RFC, but there's high interest for some solution along those lines

And just a note, this is called Reader monad in Haskell

In other words, receiving an implicit parameter is a kind of effect. So another way to provide this feature is to have a full blown effect system (which is much more general and is probably overkill, but there's also some interest for that)

How is that much different than just using malloc and then letting the OS clean up when the process exits?

By having implicit arguments, a framework can decide when to override the implictness and be explicit to use a different arena when needed.

Also, many process like servers are long lived, so the OS clean up strategy does not work for them, and they are exactly where you want some strategy for memory allocation like arenas to prevent memory fragmentation.

> Implicit arguments! I'm more and more convinced that this form of controlled dynamic scoping dynamic scoping should be embraced by more languages.

This might be an odd comment, but this is sorta similar to React's Context mechanism. For what it's worth, it makes a lot of things easier but it can definitely also add a lot of surface area for complexity. Although it's certainly better than relying on globals all over the place.