Hello,
On Tue, 21 Jan 2025, Martin Uecker wrote:
> > > Coudn't you use the rule that .len refers to the closest enclosing
> > > structure
> > > even without __self__ ? This would then also disambiguate between
> > > designators
> > > and other uses.
> >
> > Right now, an expression cannot start with '.', which provides the
> > disambiguation between designators and expressions as initializers.
>
> You could disambiguate directly after parsing the identifier, which
> does not seem overly problematic.
Which way? When you allow ". identifier" as primary expression, then in
struct S s = { .x = 42 };
the initializer can be parsed as designated initializer (with error
when 'x' is not a member of S) or as assignment expression like in
struct T t = { foo = 42 };
You need to decide which is which after seeing the ".". I'm guessing what
you mean is that on seeing ".ident" as first two tokens inside in
initializer-list you go the designator route, and not the
initializer/assignment-expression route, even though the latter can now
also start with ".ident". But then, what about:
struct U u = { .y };
It's certainly not a designation anymore, but you only know after not
seeing the '='. So here it's actually an assignment-expression. And as
you allowed ".ident" as primary expression this might rightfully refer to
some in-scope 'y' member of some outer struct (or give an error).
Note further that you may have '{ .y[1][3].z }', which is still not a
designation, but an expression under your proposal, whereas
'{ .y[1][3].z = 1 }' would remain a designation. This shows that you
now need arbitrary look-ahead to disambiguate the two. A Very Bad Idea.
Ciao,
Michael.
