Hi Joseph, On 11/14/22 19:13, Joseph Myers wrote:
On Sun, 13 Nov 2022, Alejandro Colomar via Gcc wrote:SYNOPSIS: unary-operator: . identifierThat's not what you mean. See the standard syntax.
Yup; typo there.
unary-expression: [other alternatives] unary-operator cast-expression unary-operator: one of & * + - ~ !- It is not an lvalue. - This means sizeof() and _Lengthof() cannot be applied to them.sizeof can be applied to non-lvalues.
thinko there. I fixed it in a subsequent email.
- This prevents ambiguity with a designator in an initializer-list within a nested braced-initializer.No, it doesn't. See my previous points about syntactic disambiguation being a separate matter from "one parse would result in a constraint violation, so choose another parse that doesn't" (necessarily, because the constraint violation that results could in general be at an arbitrary distance from the point where a choice of parse has to be made). Or see e.g. the disambiguation rule about enum type specifiers: there is an explicit rule "If an enum type specifier is present, then the longest possible sequence of tokens that can be interpreted as a specifier qualifier list is interpreted as part of the enum type specifier." that ensures that "enum e : long int;" interprets "long int" as the enum type specifier, rather than "long" as the enum type specifier and "int" as another type specifier in the sequence of declaration specifiers, even though the latter parse would result in a constraint violation later.
I get it. It's only unambiguous if there's lookahead.
Also, requiring unbounded lookahead to determine what kind of construct is being parsed may be considered questionable for C. (If you have an initializer starting .a.b.c.d.e, possibly with array element access as well, those could all be designators or .a might be a reference to a parameter of struct or union type and .b.c.d.e a sequence of references to members within it and disambiguation under your rule would depend on whether an '=' follows such an unbounded sequence.)
I'm thinking of an idea for this.
- The type of a .identifier is always an incomplete type. - This prevents circular dependencies involving sizeof() or _Lengthof().We have typeof as well, which can be applied to expressions with incomplete type.
Yes, but it would not be problematic in the two-pass parsing I have in mind.
- Shadowing rules apply. - This prevents ambiguity."Shadowing rules apply" isn't much of a specification. You need detailed wording that would be added to 6.2.1 Scopes of identifiers (or equivalent elsewhere) to make it clear exactly what scopes apply for identifiers looked up using this construct.
Yeah, I guess. I'm being easy for this draft. I'll try to be more precise for future revisions.
- void foo(struct bar { int x; char c[.x] } a, int x); Explanation: - Because of shadowing rules, [.x] refers to the struct member.I really don't think standardizing VLAs-in-structures would be a good idea. Certainly it would be a massive pain to specify meaningful semantics for them and this outline doesn't even attempt to work through the consequences of removing the rule that "If an identifier is declared as having a variably modified type, it shall be an ordinary identifier (as defined in 6.2.3), have no linkage, and have either block scope or function prototype scope.".
Maybe. I didn't have them in mind until Martin mentioned them. Now that he mentioned them, I'd like at least to be careful so that any new syntax doesn't do something that impedes adding them in the future, if it is ever considered desirable.
The idea that .x as an expression might refer to either a member or a parameter is also a massive change to the namespace rules, where at present those are in completely different namespaces and so in any given context a name only needs looking up as one or the other. Again, proposals should be *minimal*.
Yes. I only want to have a rough discussion about how the entire feature in an ideal future where everything is added would look like. Otherwise, adding a minimal feature without considering this future, might do something that prevents some part of it being implemented due to backwards compatibility.
So I'd like to discuss the whole idea before then going to a minimal proposal that will be *much* smaller than this idea that I'm discussing.
I'm happy with the Linux man-pages implementing the whole idea (even if it's impossible to implement it in C ever), and letting ISO C / GCC implement initially (and possibly ever) only the minimal stuff.
And even when they are, many issues may well arise in practice (see the long list of constexpr issues in my commit message for that C2x feature, for example, which I expect to turn into multiple NB comments and at least two accompanying documents).
Sure; I expect that. Cheers, Alex
-- <http://www.alejandro-colomar.es/>
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature
