C compilers still support old-style function argument syntax. They have to, for backwards compatibility. Plenty of actively-developed software being compiled on modern versions of the C standard still has some older functions whose signatures are written in K&R style.
Ok so K&R style is going to be removed (good!) as others have pointed out. The compiler could provide a tool to automatically update the function signatures, making it relatively easy to update legacy code.
Also, it seems to me that anyone who wants the best for C would want to get rid of the context-sensitive parsing. So that would include those on the standards committee. Here's hoping they can continue improving the language over time, albeit slowly.
It has already been deprecated for decades, but I doubt they will ever remove it. Compatibility with millions of lines of pre-existing code is simply more important than the somewhat niche concern that it makes C harder to parse.
And we’re talking about something from the premodern time of C. Changing how declarations are written now is a complete non-starter; there would be absolutely zero appetite for that, and even if the standards committee did it, everyone would just continue using compiler flags for the last version of the standard before the change happened, so compilers and parsers would have to continue supporting it anyway.
> Surely C has deprecated something
Again, deprecated yes, but the only thing I can actually think of them removing outright is the gets function, which had way more potential to cause harm than these parsing issues.
I think you are just massively overestimating the extent to which the C committee is willing to break things. The language is managed and standardized in a totally different way from things like Python.
Well, it so happens that C23 has so far been decided to remove K&R function declarations! (the "int fn() int arg1, arg2; { /*code*/ }" kind) So it's not utterly impossible for old things to get removed (though who knows if that'll change).
But C syntax really isn't the biggest problem in this. Even if you decide to write a whole new C parser for your new language, you'd still need to support the 176 ABI triples (or not work on many systems) and detect & choose which one the user's system uses. It wouldn't be hard to reduce that number by a lot if anyone actually would've tried to.
Architectures do differ, but there's really not a good reason to have dozens of ABIs per architecture. But that's what we have - 15 for aarch64, 9 for armv7, 27 for x86-64, etc. Most things in each set most likely do match, but there's no specification of how they do, so it's hard to consider them in a way other than just a dozen different ABIs that might as well be for different architectures.
