The answer to most post-C89 features could be just use C++, but yeah, changing human nature is a lost fight.
We need a "C++ lite".
We do this by moving features from C++ to C, bit-by-bits, until C become bloated.
void foo(int X, int Y) { double a[X][Y]; .. }
In fact, this is one reason I switched away from C++, because arrays are so bad in C++.
(yes, one can activate library assertions, but still - by default - unsafe)
... is somewhat understatement.
It this point, if I want generics, I'd rather just use C++.
At least in C there's a possibility to learn from C++'s mistakes, and only integrate the 'good parts' (and the C++ template system certainly isn't one of those good parts).
In any case, if you need a clean subset of C++ (but nobody I have met really agreed about what this is) nobody is stopping you from defining one.
Overall? Without a doubt. But these specific features they've been adding are implemented very unnecessarily strangely just to avoid fully committing to them, so that they end up in this design space where they may not be weirder than the full Lovecraftian horror of the equivalent C++ feature, but they are much weirder than the ideal/abstract concept of the equivalent C++ feature, which is what I wish they would have pulled in. Like, looking at this proposal, it isn't clear to me at all how the compiler is actually compiling or the runtime is executing these polymorphic function calls at all, in cases where they don't just collapse to void*. And it isn't clear to me how exactly type scoping and substitution works either. Whereas in concept at least templates are crystal clear and also easy to expand to do much more advanced macro-less metaprogramming, like D does.
> and often think some parts are weird simply because they are different.
I have way more experience with C than C++, but I'm usually a Rust programmer which works more like C++ so maybe that's where my bias is, but I really think this implementation is unnecessarily weird in general too — I've used a lot of languages.
To me it is crystal clear how this will work, and I much prefer this to generics in C++ and Rust or other similar languages.
But I am not saying it is wrong what C++ and Rust does. So if you prefer this, those languages are there ready to be used. I just think there should also be a good alternative for people who do not like how this works there.
That's what Rust looked like in the beginning - a better C++. But that seems to be getting corrupted by a bunch of language designers too now.
Showing up at WG21 is much more appealing to most folks.
Maybe compare how C23 compares to C89, and future roadmap.
...and let's just hope it stays that way ;)
Also, Ada has a very decent interop with C. To the point that w/o any prior experience, I needed to use some functions from SQLite that weren't already exposed through Ada, and it was a pretty smooth sailing: very little "glue" code, all code that connected C and Ada was written in Ada.
Personally I am not a big fan, because it doesn't have a good story for use-after-free (other than adopting similar analyser tooling like C derived languages), if I want to type @ all over the place I can use Objective-C, and the community doesn't seem very keen in supporting binary library distribution.
That is me, we don't have to like all the same things.
Even with UAF caveat, it still better than plain old C.
Personally I find Odin more appealing than Zig.