Very good questions.
The way Zig seems to handle this is by explicitly pushing around a memory allocator. Jai on the other hand provides a thread local ”context” that’s hidden in every call. I think that is a better idea actually since it can just stay in a reserved register across all calls.
However, not even this is strictly necessary if we consider it a ”built in” implementation that just happens to have first class handling. It’s a convenience and not a high performance tool.
The same then goes for the maps and strings: they either bundle an allocator or uses some default one.
The map can be limited to ints and strings for keys. No memory management is done for values and strings are refcounted and lazy copied by default. Maps and arrays could always be passed ”by reference” to mimimize magic.
The key idea here is to think Pascal strings: they made string handling easy compared to C++
for simple tasks. This is so that when you want to just do some simple string handling you can actually do that with something built in that makes the simple tasks easy.
Using growing arrays in highly performance critical code is a no-no. Same with doing high speed templating work. But for these cases you should have custom solutions anyway.
I think the imolementations you get from C++ with STL’s map/vector/string is about what you need. However, for C2 we can’t really solve the problem that way (because of missing generics and overloading)
These are my current state of ideas anyway. I might end up with the opposite conclusion eventually