Am Donnerstag, den 10.11.2022, 23:19 +0000 schrieb Joseph Myers:
> On Thu, 10 Nov 2022, Martin Uecker via Gcc wrote:
>
> > One problem with WG14 papers is that people put in too much,
> > because the overhead is so high and the standard is not updated
> > very often. It would be better to build such feature more
> > incrementally, which could be done more easily with a compiler
> > extension. One could start supporting just [.x] but not more
> > complicated expressions.
>
> Even a compiler extension requires the level of detail of specification
> that you get with a WG14 paper (and the level of work on finding bugs in
> that specification), to avoid the problem we've had before with too many
> features added in GCC 2.x days where a poorly defined feature is "whatever
> the compiler accepts".
I think the effort needed to specify the feature correctly
can be minimized by making the first version of the feature
as simple as possible.
> If you use .x as the notation but don't limit it to [.x], you have a
> completely new ambiguity between ordinary identifiers and member names
>
> struct s { int a; };
> void f(int a, int b[((struct s) { .a = 1 }).a]);
>
> where it's newly ambiguous whether ".a = 1" is an assignment to the
> expression ".a" or a use of a designated initializer.
If we only allowed [ . a ] then this example would not be allowed.
If need more flexibility, we could incrementally extend it.
> (I think that if you add any syntax for this, GNU VLA forward declarations
> are clearly to be preferred to inventing something new like [.x] which
> introduces its own problems.)
I also prefer this.
I proposed forward declarations but WG14 and also people in this
discussion did not like them. If we would actually start using
them, we could propose them again for the next revision.
Martin
