On Sat, 12 Nov 2022, Alejandro Colomar via Gcc wrote:
> > struct s { int a; };
> > void f(int a, int b[((struct s) { .a = 1 }).a]);
>
> Is it really ambiguous? Let's show some currently-valid code:
Well, I still don't know what the syntax addition you propose is. Is it
postfix-expression : . identifier
(with a special rule about how the identifier is interpreted, different
from the normal scope rules)? If so, then ".a = 1" could either match
assignment-expression directly (assigning to the postfix-expression ".a").
Or it could match designation[opt] initializer, where ".a" is a
designator. And as I've noted many times in discussions of C2x proposals
on the WG14 reflector, if some sequence of tokens can match the syntax in
more than one way, there always needs to be explicit normative text to
disambiguate the intended parse - it's not enough that one parse might
lead later to a violation of some other constraint (not that either parse
leads to a constraint violation in this case).
Or is the syntax
array-declarator : direct-declarator [ . assignment-expression ]
(with appropriate variants with static and type-qualifier-list and for
array-abstract-declarator as well, and with different identifier
interpretation rules inside the assignment-expression)? If so, then there
are big problems parsing [ . ( a ) + ( b ) ], where 'a' is a typedef name
in an outer scope, because the appropriate parse would depend on whether
'a' is shadowed by a parameter - unless of course you add appropriate
wording like that present in some places about not being able to use this
syntax to shadow a typedef name.
Or is it just
array-declarator : direct-declarator [ . identifier ]
which might avoid some of these problems at the expense of being less
expressive?
If you're proposing a C syntax addition, you always need to be clear about
exactly what the new cases in the syntax would be, and how you resolve
ambiguities with any other existing part of the syntax, how you interact
with rules on scopes, namespaces and linkage of identifiers, etc.
--
Joseph S. Myers
[email protected]
