Obvious things C should do

I think you're focused on something that D programmers found helpful, rather than focusing squarely on the needs of C programmers. C and D are both good languages. Their use cases can overlap, but frequently don't.

>=70% of the code I write for work is C, as I'm an embedded firmware dev. C meets the very particular needs of bare-metal development, a use case that continues to be underserved by Rust, Zig, and other supposed successors to C. So, I'll be approaching this with a strong bias towards that perspective.

To me, the argument about unit testing rings hollow because of all the other, far more complicated and runtime-subverting things that would also need to become standardized before it would be feasible to unit test C programs without help from the hideous hacks we use today, like CMock. So, all of that isn't doing anything for me.

> My proposal (and D) does not require constexpr. The same function can be used at run or compile time.

Like you, I dislike the constexpr keyword. But, particularly considering your own example of defining an enum value, I don't see how the "implicit const-evaluatable" approach makes my life easier. Calling functions to define an enum's value is cute, but I can't tell you why I'd actually want to do that. You mention that the preprocessor can't handle floats, but, well, neither can enums!

Adding a single printf (or, in my case, kprintf or LOG_DBG or whatever) would become liable to nuke some constant evaluation happening somewhere far up an obscure call chain. The basic reality of C is that you will, at one point or another, encounter a situation where your only debugging tool is print statements (or a single LED). That's the cold reality of C's paper-thin runtime.

So, I really dislike the idea of having a feature that's liable to make your code go "boom" at compile time because you put a print statement in just the wrong spot. Or a write to a memory-mapped register. Or a hard jump into a blob sitting somewhere in memory. Or inline assembly. Or a call to a function that uses any of those things, even once. Even without the keyword, you end up with red functions and blue functions. It's just harder to tell which ones are which.

Defining some const floats? Sure, that's neat. If you could use this feature to define huge matrices of floats, that'd be pretty cool! There's just a boatload of gotchas.

Every time you do exploratory work you now have to comment out all the tests that this work breaks because otherwise it won't compile anymore.

That would be even more annoying than Go's stupidly pedantic compiler.

- add support for a slice type that encodes a pointer and length

- make re-entrant and ideally threadsafe APIs for things that currently use global state (including environment variables).

- standardize something like defer in go and zig, or gcc's cleanup attribute

- Maybe some portable support for unicode and utf-8.

Firstly, there are at least 3 C compilers in widespread use, from apple, microsoft and gnu, these are a long way from 1 for 1 to each other so when it says for example:

->In other words, while C can compute at compile time a simple expression by constant folding, it cannot execute a function at compile time.

Maybe the compiler he tried cannot, but another can, no idea, it wasnt tested, they can be made to (the whole point of the article), apple and microsoft cannot be made to, everything in this article could have have been submitted as a merge request to gnu.... Article doesnt even state whose C compiler they embedded afaict.

wrt to "standard" c specifically, there are for sure some hard constraints on all the wild and wacky hardware support required that must make proposing and implementing changes within the c standard extremely hard, max respect to the anonymous experts that have got it to where it is today, but imho a lot of the "why doesnt c" questions can be as easily answered as "why doesnt V8 support 8 bit pic micros".