Am Donnerstag, dem 15.06.2023 um 16:55 +0000 schrieb Joseph Myers:
> On Thu, 15 Jun 2023, Qing Zhao via Gcc-patches wrote:
>
...
> > 1. Update the routine “c_parser_postfix_expression” (is this the right
> > place? ) to accept the new designator syntax.
>
> Any design that might work with an expression is the sort of thing that
> would likely involve many iterations on the specification (i.e. proposed
> wording changes to the C standard) for the interpretation of the new kinds
> of expressions, including how to resolve syntactic ambiguities and how
> name lookup works, before it could be considered ready to implement, and
> then a lot more work on the specification based on implementation
> experience.
>
> Note that no expressions can start with the '.' token at present. As soon
> as you invent a new kind of expression that can start with that token, you
> have syntactic ambiguity.
>
> struct s1 { int c; char a[(struct s2 { int c; char b[.c]; }) {.c=.c}.c]; };
>
> Is ".c=.c" a use of the existing syntax for designated initializers, with
> the first ".c" being a designator and the second being a use of the new
> kind of expression, or is it an assignment expression, where both the LHS
> and the RHS of the assignment use the new kind of expression? And do
> those .c, when the use the new kind of expression, refer to the inner or
> outer struct definition?
I would treat this is one integrated feature. Essentially .c is
somthing like this->c for the current struct for designated
initializer *and* size expressions because it is semantically
so close. In the initializer I would allow only
the current use for designated initialization for all names of
member of the currently initialized struct, so .c = .c would
be invalid. It should never refer to the outer struct if there
is a member with the same name in the inner struct, i.e. the
outside member is then hidden.
So this would be ok:
struct s1 { int d; char a[(struct s2 { int c; char b[.c]; }) {.c=.d}.c]; };
Here the use of .d would be ok because it is not from the struct
currently initialized, but from an outside scope.
Martin
