On Thu, 15 Jun 2023, Qing Zhao via Gcc-patches wrote:
> Comparing B with A, I don’t see too much benefit, either from
> user-interface point of view, or from implementation point of view.
>
> For implementation, both A and B need to search the fields of the
> containing structure by the name of the field “count”.
>
> For user interface, I think that A and B are similar.
But as a language design matter, there are no standard C interfaces that
interpret a string as an identifier, so doing so does not fit well with
the language.
> 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?
There are obvious advantages to using tokens that don't introduce such an
ambiguity with designators (i.e., not '.' as the token to start the new
kind of expression, but something that cannot start a designator), if such
tokens can be found. But you still have the name lookup question when
there are multiple nested structure definitions. And the question of when
expressions are considered to be evaluated, if they have side effects such
as ".c=.c" does.
"Whatever falls out of the implementation" is not a good approach for
language design here. If you want a new kind of expressions here, you
need a careful multi-implementation design phase that produces a proper
specification and has good reasons for the particular choices made in
cases of ambiguity.
--
Joseph S. Myers
jos...@codesourcery.com
