Hi David,
Am Donnerstag, dem 13.03.2025 um 19:23 -0700 schrieb David Tarditi: > > I skip your initiial part. I think this was all discussed before (also in WG14) and I still come to different conclusions. Just two comments: ... > > The VLA semantics are also problematic. User can side-effect > variables used in a VLA declaration after the declaration, while > the declaration is in scope. It is not obvious how to implement > bounds checking, because the bounds could be gone (invalid). > It is a design flaw that the declared bounds can become invalid > while the declaration is in scope. Variably modified types do not work like this C. The size expression is evaluated at the point of declaration. If there is a variable in it, it is never accessed later and changing it does not affect the type anymore. int len = 1; char buf[len]; // len is evaluated and the array has size 10 len = 10; // has no impact on the type of 'buf' In fact, one can also have more complicated expressions. int len = 11; char buf[len + 1]; // has size 11. and those are also not re-evaluated later. This is exactly how it works in other dependently types languages, so I do not think one can make the case that C got these semantics wrong. Bounds checking also works already today: https://godbolt.org/z/5P8so1reb (although there are still missing pieces which would be important but which compilers currently do not implement. But for GCC I have a local branch which adds most of those.) > > Finally, when you get to nested pointers, the syntax (and typing) > for VLAs becomes confusing. This isn’t VLAs fault. It is there in the > original C design. Your comments about C's syntax certainly have some truth to them, but I personally - as a C programmer and teacher - would find it much worse to add new inconsistent rules to the language just to be able to write something in a more succinct way in some specific cases. A programmer would still have to learn and nderstand the general C syntax and all the existing rules name lookup rules. I do not think adding new inconsistent rules would make the language simpler and clearer in general, even it it may look like this when only considering a narrow use case. Martin
