Nobody in the trenches seemed to use old-style auto in the last decades.
BTW: The right place to complain if you disagree would be the compiler vendors. In particular the Clang side pushes very much for keeping C and C++ aligned, because they have a shared C/C++ FE. So if you want something else, please file or comment on bugs in their bug tracker. Similar for other compilers.
> Nobody in the trenches seemed to use old-style auto in the last decades.
To the beat of my knowledge, there was no case where "auto" wasn't redundant. See e.g. https://stackoverflow.com/a/2192761
This makes me feel better about repurposing it, but I still hate the shitty use it's been put to.
Indeed, however many in the treches would like a more serious take on security, complaining has not served anything in the last 50 years until goverment agencies finally decided to step in.
This is again a problem compilers could have addressed, but didn't. Mostly because the users in the trenches did not care. Instead they flocked in droves to the compiler optimizing in the most aggressive way and rejecting everything costing performance. So I do not have the feeling that users were really pushing for safety. They are very good at complaining though.
GCC and Clang support asan/ubsan, which lets you trade performance for nicer behavior related to memory access and undefined behavior. Whenever I do C development for a platform that supports asan/ubsan, I always develop and test with them enabled just because of how much debugging time they save.
It is like democracy, election results not always reflect the needs of everyone, and some groups are more favored than others.
I think my point is that a standardization committee is not a government.
It surely looks like one from the outside.
Features only get added when there is a champion to push for them forward across all hurdles (candidate), and voted in by its peers (election), at the end of a government cycle (ISO revision), the compiler users rejoice for the new set of features.