> Nah, just use Arenas/Pools. Or don't use heap at all.
This will solve more than 90% of problems. I'll also add that replace C pointers with a "Fat Pointer" or Go-like slice struct and avoid the C stdlib. Then you'll have fixed 99% of issues.
Custom allocators are pretty useful, yes. And slices, although it would be nice to have an easy syntax for using them.
Still have null pointers though. So an optional type would be useful too. Billion dollar mistake and all. Oh, and you have to check errno, might want a better way to handle errors so that you have to check them, or at least acknowledge that they exist. Probably need a linter to make those stick, you really do want violating a nullability constraint to fail at compile time.
And yeah, you have to avoid libc now, but it has so much useful stuff! So we'd want a library that offers all that useful stuff, but uses our fancy custom allocators, and optionals, and error checks, and slices.
While we're dreaming, wouldn't namespaces be nice? Like you have a function do_bar on a struct Foo type, so there's this foo_do_bar function (almost like a method), it'd be nice to be able to just say foo.do_bar, y'know?
Of course, at that point, you've almost got a whole different language! But it can compile and link with C, so yeah, best of both worlds.
Err.. Why does one need to even use a different language to implement Arenas and Slices? Yes having syntax level support for them would indeed be nice (something like new languages like Odin and Zig are trying) but you can start using them today and make programming in C an order of magnitude better.
This will solve more than 90% of problems. I'll also add that replace C pointers with a "Fat Pointer" or Go-like slice struct and avoid the C stdlib. Then you'll have fixed 99% of issues.