Am Montag, dem 10.03.2025 um 15:00 -0400 schrieb John McCall:
>
...
> That said, my preference is still to just give preference to the field name,
> which sidesteps any need for disambiguation syntax and avoids this whole
> problem where structs can be broken by just adding a global variable that
> happens to collide with a field.
I don't think it is a good idea when the 'n' in 'buf' refers to the
previous global 'n' coming before and the 'n' in attribute
refers to a member 'n' coming later in the following example.
constexpr int n = 1;
struct foo {
char *p [[gnu::counted_by(n)]];
char buf[n];
int n;
};
How are you going to explain this to anyone?
And neither global names nor struct members may always be under
the control of the programmer. Also that simply bringing
a new identifier into scope can break code elsewhere worries me.
Finally, the following does not even compile in C++.
struct foo {
char buf[n];
const static int n = 2;
};
While the next example is also ok in C++.
constexpr int n = 2;
struct foo {
char buf[n];
};
With both declarations of 'n' the example has UB in C++.
So I am not convinced the proposed rules make a lot
of sense for C++ either.
Disambiguation with '__self__.' completely avoids all these issues
while keeping the door open for later improvements.
I still think one could use designator syntax, i.e. '.n', which
would be clearer and intuitive for both C and C++ programmers.
Martin
