On Wed, Mar 30 2022, Junio C Hamano wrote: > We raised the weather balloon to see if we can allow the construct > in 44ba10d6 (revision: use C99 declaration of variable in for() > loop, 2021-11-14), which was shipped as a part of Git v2.35. > Document that fact in the coding guidelines, and more importantly, > give ourselves a deadline to revisit and update. > > Let's declare that we will officially adopt the variable declaration > in the initializaiton [...] Typo: initialization. > part of "for ()" statement this winter, unless we find that a platform > we care about does not grok it. I'd think that waiting a couple of releases would be sufficient for this sort of thing. I.e. contributors to this project already have access/knowledge about a wide variety of compilers, especially the "usual suspects" (mainly MSVC) that have been blockers for using new language features in the past. So I'm in no rush to use this, and the winter deadline sounds fine to me in that regard. But on the other hand I think the likelihood that waiting until November v.s. May revealing that a hitherto unknown compiler or platform has issues with a new language feature is vanishingly small. > A separate weather balloon for C99 as a whole was raised separately > in 7bc341e2 (git-compat-util: add a test balloon for C99 support, > 2021-12-01). Hopefully, as we find out that all C99 features are OK > on all platforms we care about, we can stop probing the features we > want one-by-one like this Unfortunately this really isn't the case at all, the norm is for compilers to advertise that they support verison X of the standard via these macros when they consider the support "good enough", but while there's still a long list of unimplemented features before they're at 100% support (and most never fully get to 100%). We also need to worry about the stdlib implementation, and not just the compiler, see e.g. the %zu format and MinGW in the exchange at https://lore.kernel.org/git/220318.86bky3cr8j.gmgdl@xxxxxxxxxxxxxxxxxxx/ and https://lore.kernel.org/git/a67e0fd8-4a14-16c9-9b57-3430440ef93c@xxxxxxxxx/; But I think we're thoroughly past needing to worry about basic language features in C99 such as these inline variable declarations. > (it does not necessarily mean that we would automatically start using > any and all C99 language features, though). Yes, particularly those that the standards committee backed out of or made optional after C99 would be good candidates for avoiding permanently.
