Comment by CyberDildonics
3 months ago
The problem is that C semantics leads to C problems that the world has dealt with for decades.
It sounds like you are leaving tried and tested simple advancements in programming on the table just to avoid a superficial comparison.
Even then what C++ people want from a competitor is simplicity. Not to give up the essentials but to keep the crucial aspects that they can never give up and are the reason they put up with all of the complexity of C++.
Personally I think it is reasonable that a C alternative is an alternative to C, and not a C++ alternative. C3 uses a temp allocator that removes a large number of cases where C++ would need RAII to manage memory. Did you try C3?
Does it just deallocate at the end of a scope? Why go halfway? It's obviously valuable and destructors are not complicated. Destructors can also close files, sockets, deallocate buffers from the GPU, etc.
I think when people want C semantics they will just use C in general, but if there is something that solves these extreme pain points in a simple way it might be enough to get someone to switch.
The temp allocator is a stack allocator, so it's a bit more flexible than that and can be used for return values or even more long lived allocations. It doesn't use the standard heap allocator to alloc, so there is a potential win in speed and cache coherence as well.
For scoping files, sockets and so on, there's actually a simple mechanism in C3 that allows creating code like that very easily using macros with "trailing body". Which is a little like trailing closures in Swift, but here there is no closure, just a macro.
There is an example here: https://c3-lang.org/generic-programming/macros/#trailing-blo... but it's used in the stdlib quite a lot.
4 replies →
Yes the temp allocator will remove things at the end of it's scope. It makes it very clear when memory will be affected and gives predictable code execution.
There are other contexts for managing mutex locks so they auto close and you could dream up one for database connections and transactions too.
The nice things about a context is you can always see it's there, destructors by design are a bit hidden which can make code harder to reason about.
1 reply →