Hi Joseph, On 11/11/22 00:19, Joseph Myers wrote:
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". 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. (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.)
Yeah, I think limiting it to [.n] initially, and only moving forward, step by step, if it's perfectly clear that it's doable seems very reasonable.
Re: GNU VLA fwd decl:
This example is what I'm worried about:
int foo(int a; int b[a], int a);
int foo(int a, int b[a], int o);
Okay, parameters should have more readable names... But still, it allows for a
high chance of wtf moments. However, I can think of a syntax very similar to
GNU's, that would make it a bit better in terms of readability: not declaring
the type in the fwd decl:
int foo(a; int b[a], int a);
int foo(int a, int b[a], int o);
Cheers,
Alex
--
<http://www.alejandro-colomar.es/>
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature
