Comment by stevendgarcia
3 days ago
Great feedback!
You’re absolutely right — C and C++ give you the primitives to do this manually. If every developer followed the “stack first, heap only when necessary” discipline, and carefully used unique_ptr or avoided new/delete when possible, you could achieve much of the same safety and determinism.
The difference I’m aiming for is that these constraints aren’t optional — they’re baked into the language and compiler. You don’t rely on every developer making the right choice; instead, the structure of the code itself enforces ownership and lifetime rules.
So in your terms, instead of “doing dumb things is an error,” it’s structurally impossible to do dumb things in the first place. The language doesn’t just punish mistakes with foot-guns, it makes the safe path the only path.
This also opens up other possibilities that are really awkward in C/C++, like structured concurrency with deterministic memory cleanup, restartable scopes, and safe parallel allocations, without relying on GC or heavy reference counting.
I’d be curious: if C++ had a compiler that made stack-first allocation the default and forbade escapes unless explicit, would that solve most of the problems you’ve experienced, or are there still edge cases that would require a fundamentally different runtime model?
As far as I'm concerned, stack-first allocation _is_ the default. It's true that the default exists in my head rather than in in a compiler, though.
Maybe think about whether what you propose could exist as a compiler warning, or static analysis tool. Or, if you want to create your own language, go for it, that's cool too.
For my purposes... the choice of paradigms, compilers, platforms with C++ and ability to handle and work on decades of existing code outweighs the benefits of "improved" languages, but that's just me.