Hi Mark, > Date: 2026-09-14 10:19:13-0700 > From: Mark Harris > > Alejandro Colomar wrote: > > > Anyway N3207 (spec mentioned in d2c2db883) is something I'll need to get used to :). > > > > There's a more recent paper with a slightly better spec (also compatible > > with GCC): N3681. > > > > There is an even more recent paper addressing this subject, N3923 > , Indeed, there's that newer proposal. It's a different one, though. > and the > outcome from the last WG14 meeting was strong direction to proceed > along these lines. The actual poll results are 15 in favour, 7 against, and 4 abstentions. I wouldn't have called that "strong direction to proceed". I know that's what the minutes say, but I don't agree with how polls are taken as strong direction. 7 votes against is quite vocal opposition. Here's a summary of the room feelings: The committee was more or less (including myself) saying "as a user, I'd like it, but as an implementor, it'd probably be a nightmare; as long as implementors are okay with it, we're fine". There was a comment from one implementor of a small C compiler which essentially said it was un-implementable for them, which raised some concerns. From the minutes: Uecker: The SlimCC developer and another compiler developer wrote in a discussion about general features that they are worried about parameters for active declaration scoping. It is difficult for them to implement this. They would rather implement template C++ functions. I suggested a way forward: first, write a proposal prohibiting the use of parameter names in array length expressions that clash with variables declared at an outer scope. The wording would look like this (taken from n3923 itself): 6.7.7.4 Function declarators @@ p4+1 +Within a parameter declaration list, +if an identifier used in a parameter’s array bound expression +refers to a name declared later in the same list, +no declaration of an identifier with the same name +shall be visible from an enclosing scope. This would require that the following code results in a diagnostic: int n; void foo(int a[n], int n); But it would allow the following code without diagnostics: int n; void bar(int n, int a[n]); void baz(int a[n]); This is obviously a good constraint, since it disallows code that is most likely already broken, and doesn't affect code that works fine. Once that constraint is in place, we could add --as a second proposal-- retroactive declaration of parameters being optional (so that small compilers can say they don't support it), but we'll be sure that code will not misbehave on such compilers. > Hopefully this much more human-readable approach > will prevail and we can do away with these confusing forward > declarations in parameter lists. Agree. Have a lovely day! Alex > > - Mark --