Good question. I haven't mentioned memory management because it's not done yet. I know for sure there won't be a GC or reference counting.
I want to do something similar to Rust's approach, but much much simpler. It's not an easy task.
Right now the language handles very simple cases. Small strings are placed on the stack, local variables that are not returned are clean up automatically.
Globals are not allowed, function args can't be modified, so that helps a bit.
No GC, no reference counting, no manual memory management... Hmmm.... Not everything can be managed by RAII/SBRM... Let say I have a function which loads a complex document (like spreadsheet), does some changes, saves the document and then exits. Who will dispose this complex, dynamic document from the memory? This is the CORE question! If there is a no GC, no RC, no manual management solution to this, then I AM REALLY INTERESTED to know about it...
Yes, which is why I asked. He seems to be saying it will have the ease of GC with the performance of fully manual memory management with none of the costs of either. I don't see how radically simplifying Rust's approach can do that, but I don't have to. If he can find a partial solution that is significantly better, that will be great. I don't know if he'll succeed, but I'm rooting for him.
I want to do something similar to Rust's approach, but much much simpler. It's not an easy task.
Right now the language handles very simple cases. Small strings are placed on the stack, local variables that are not returned are clean up automatically.
Globals are not allowed, function args can't be modified, so that helps a bit.