Ideal memory management in your dream PL.

Imagine you are designing a practical relatively low-level programming language to use instead of C++. What approach to memory management would you use?

In case someone asks, ``what is wrong with manly manual memory management in C++?'', I would briefly explain my disdain towards it. C++ strives to allow for efficient programs to be written, yet you have to jump through hoops and remember 30 different things if you want to avoid inefficiences C++ compilers inject into your application code. Where C would hit the spot with passing of pointers, C++ programmers need to know about RVO and const references and rvalues and perfect forwarding and noexcept declaration of copy constructors (why even have copy constructors anyway‽ how sane is having such thing‽) and reference collapsing rules. All just to prevent compiler from inserting procedures that needlessly copy your data multiple times here and there.

Instead of fixing a conceptually shitty design the committee adds 5 even more shitty things, each with its own semantics, each designed to work around one compiler/stdlib deficiency or another. Each has to be used manually.

So C++ programmers spend their brain cycles on recalling hundreds of shitty techniques while churning out code doing stuff which would be trivial for a saner language compiler to infer, instead of focusing on actual functionality.

Since it is lunch time where I work, I want to fantasize about a language/compiler which has most or all benefits of fast memory management (no GC), takes modern hardware into account, and doesn't fucking get in your way every time you pass a string to a function.

>>54

Symta's motto for memory management is "no heap - no garbage". By using just stack we can compact incrementally and use stack frames naturally as garbage collector generations: when a function leaves a stack frame, all frame's data is freed or compacted to parent frame. A good example would be a video game engine `render_frame`, allocating a lot of per frame data, which won't be needed for the next frame. Stack provides explicit, intuitive and predictable way to manage memory.

Rust does this. It's not enough for 100% of use cases, which is why the system is extended with other features like refcounted heap objects.

>>55
If the compiler can statically determine that a memory object will outlive the context in which it was first allocated, and also identify the context in which it should be deallocated, then it can be allocated in the latter context's stack frame.