| > This is basic compiler design stuff that surely the WG14 heads are capable of. What I don’t understand is why WG14, specifically, should be doing this. In my mind it seems obvious that WG14 just shouldn’t care about fixing deep issues with C—issues that would require high amounts of engineering effort to adopt. A new array type certainly falls in this category. C99 introduced VLAs—not even really a new array type—and these were so poorly adopted that VLAs were made optional in the next revision. You might also consider Annex K, which is also quite poorly adopted. If you want to use Microsoft’s checked C, you can use it. If you want to use MISRA, you can use that. If you want to use formal methods, there are various subsets of C that you can tackle with formal methods. If you want to use asan, tsan, valgrind, or switch to Zig or Java or Rust, all of those options are available. The problems with adding a new array type to the language are that: 1. If WG14 makes a change like you suggest, it will be poorly adopted, meaning that it's a poor fit for the standard, (just based on the history of the adoption of things like VLAs and Annex K, this is the most likely outcome). 2. You can just use a different language for new projects, or extensions / tooling for existing projects. In other words, it’s a low value change with a high cost. > I really don't get your "maintain compatibility with existing code" hot discussion. It’s because your original comment was so short and vague. Feel free to ignore the responses, since you’ve since clarified. |
Your suggestion to use something else is a bit hard on platforms where C is the name of the game.
I am mostly C clean since 1992, unless required otherwise, not everyone is free to chose their tooling, nor what language the software they use, e.g. UNIX kernels or IoT junk, was written on.